From internet-drafts@ietf.org Mon Oct 1 04:25:14 2012 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 378D121F8533; Mon, 1 Oct 2012 04:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNIw5GMiois5; Mon, 1 Oct 2012 04:25:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810A921F860B; Mon, 1 Oct 2012 04:25:13 -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.34 Message-ID: <20121001112513.3691.55739.idtracker@ietfa.amsl.com> Date: Mon, 01 Oct 2012 04:25:13 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-01.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: Mon, 01 Oct 2012 11:25:14 -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 : WebSocket Per-message Compression Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-permessage-compression-01.txt Pages : 18 Date : 2012-10-01 Abstract: This specification defines a WebSocket extension that adds compression functionality to the WebSocket Protocol. It compresses the payload of non-control WebSocket messages using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each message. This specification provides one compression method available for the extension using DEFLATE. 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-permessage-compression-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Mon Oct 1 04:54:43 2012 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 6B96121F8503 for ; Mon, 1 Oct 2012 04:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3HSlKnZs6+f for ; Mon, 1 Oct 2012 04:54:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D021F851B for ; Mon, 1 Oct 2012 04:54:42 -0700 (PDT) Received: by lbok13 with SMTP id k13so4427446lbo.31 for ; Mon, 01 Oct 2012 04:54:41 -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:x-system-of-record; bh=oakHpnmlQnihdRLf3FCtbi+dnjQi1rCUi33wKgiUvTM=; b=KygR+F84iQu2EUVEc6gWPP++lsvsGo8JEbuMg95n4AHiJLb/sLs8AJqPBvLsgVhOav qAym2hA3iJsGfYlE7TU5Z1J+V9oJFGIwOcA8HGP2/QSfmbvrzKnbRGSsPTzbZ3MnERCw /qcLSe6QYyCnnn4+m+jMkLjPZ0kbBkhrigRWZx7vsUAr64OTPsBjTyh2sCF1qjwLrqCx lralQHld8cVKbZ9/OoWlZG/4Q73kXGPNQtrIHkm2alS72TRCAvIuh4VUwfXA9cpaixKM 8k3WfR7eur3UjrRlUCzMwaEhKmQUllDFmHJtvBPlo7mxkF5yYLuvA8+kkJVvcD88DgbS 4V6g== 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-system-of-record:x-gm-message-state; bh=oakHpnmlQnihdRLf3FCtbi+dnjQi1rCUi33wKgiUvTM=; b=oovaHDm0fP213OfrhMa5o9B3T7Yr4NnsfV5x7OZOg6+pXzd0cUindpQQbJLw8GhpH/ 3qh2Rg84BwbNiifC/bu5Y0ovonrR0Nea0Z40ISccU0T+SL+YnxmprHJ2lO+XMABW8TYe pVeToiCJmhPAc88Je0lPfir7CJrCBP3AIC4ivbydtngXtUICDiQea+uwZeA+3OpNLASO 3cI6wQxwLz5OwtPD6KAFBxxubd8zBsjBoQWbkNNG5ZCBeJDD7juNPJwfYurx/YWR1HKl ZRC1ILAlpdV7IuGrtj4RiXR5bJIojyYKw7L9Lj6NjG4yBRjiOcutMmxnVJN6wB8Pf5UZ nOow== Received: by 10.152.135.41 with SMTP id pp9mr11792980lab.7.1349092481050; Mon, 01 Oct 2012 04:54:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.71.161 with HTTP; Mon, 1 Oct 2012 04:54:20 -0700 (PDT) In-Reply-To: <20121001112513.3691.55739.idtracker@ietfa.amsl.com> References: <20121001112513.3691.55739.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Mon, 1 Oct 2012 20:54:20 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=f46d044270ca1a278404cafe12ee X-System-Of-Record: true X-Gm-Message-State: ALoCoQnAK0fAeYDfRYnjWWkFhZpKKsTpCu0nGXgurdv6bbKWaGINl3AhepgL6MNrvqveeTw0Y/ZBMOxljknOECJb0Jk/dAQD7x/mkoASM5hX6CsSN+lIzvWLLgfQFCoyGN9D06JHvVFpT3G3GNhwJ7zPdtcuI7/6Khq1K1OwXgSc3+9fah8W9MXjSX1X0TrIHZbOjfLa6gTb Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-01.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: Mon, 01 Oct 2012 11:54:43 -0000 --f46d044270ca1a278404cafe12ee Content-Type: text/plain; charset=ISO-8859-1 No semantic change. - Clarified how the next block should be appended to a block with BFINAL=1 - Added texts to examples to explain what data each of the bytes contains --f46d044270ca1a278404cafe12ee Content-Type: text/html; charset=ISO-8859-1 No semantic change.

- Clarified how the next block should be appended to a block with BFINAL=1
- Added texts to examples to explain what data each of the bytes contains

--f46d044270ca1a278404cafe12ee-- From internet-drafts@ietf.org Tue Oct 2 00:07:41 2012 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 EBCCE21F8B5A; Tue, 2 Oct 2012 00:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qJEuX1ajN4y; Tue, 2 Oct 2012 00:07:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8271C21F8B58; Tue, 2 Oct 2012 00:07:39 -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.34 Message-ID: <20121002070739.23795.46412.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2012 00:07:39 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-07.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, 02 Oct 2012 07:07:41 -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 : A Multiplexing Extension for WebSockets Author(s) : John A. Tamplin Takeshi Yoshino Filename : draft-ietf-hybi-websocket-multiplexing-07.txt Pages : 41 Date : 2012-10-02 Abstract: The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. 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-websocket-multiplexing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-websocket-multiplexing-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Tue Oct 2 00:12:23 2012 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 7699421F8B5B for ; Tue, 2 Oct 2012 00:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.684 X-Spam-Level: X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le8ZyKUbQFbR for ; Tue, 2 Oct 2012 00:12:22 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8939C21F8B58 for ; Tue, 2 Oct 2012 00:12:22 -0700 (PDT) Received: by iec9 with SMTP id 9so16152074iec.31 for ; Tue, 02 Oct 2012 00:12:20 -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:x-system-of-record; bh=zE647NjD/XgLzm/4FMgNE+03DN9xTYsnFuEAcRHey9w=; b=Cxc1t1zsFaK+LxuK6VThiL6/UHunwWYjCUWN5qnlb/l4Axqkf/vXUAWmrTIM7x5zRx 8cEAVfvk2XPTGWj7ghGgvS2QAmpQ+gcO8qLu0cLYrQ8KLQnPFzR2gwjS9Hnjg9tJbdTH PIf2IyCZR/VnixkrklvpIp3OfkFAZXG51cVWSDGxWI2nFtWzSQ4UwJZdFi77QGx/PmTo cULptGaQyCvxkpxi8TnoQn67sayNEyX29b0E4s0YG7xvwU2bmK18VbcJnLFeaDCRtfLD F9qPLUWZMo/vy428dxRDPou3jPUopDv7zv7tjEaGJMUKBIg2OgJMcaeoLEm7aXMxMHCJ 3WnA== 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-system-of-record:x-gm-message-state; bh=zE647NjD/XgLzm/4FMgNE+03DN9xTYsnFuEAcRHey9w=; b=BYzEAMmkGqHwxw811BzyPgE42BF77gfQngAJMEN2eHrdEDbFJSOhAljMXWSYtS4Q2D 41CVSy1GqYltk2/LJs59jbI9ncZn+rjjucRjx+UVcHxtIh9gbOcUiu5MkJXOBDzybzzh ZoVADemhhn/x5SA+nmj/5FgIfGQe82UD593APF1WhdGEoRXAa7K/WccZ6ViqGwxJrk7B Pf1DVaw9MMWqFl+F+4toCifRxz1h2c5AfUrsS/QJDzh9WwrkH9YPfRj7fvTD7dX13W5l zz6McqV4/8fAoX7yZwdkcxkDoggsQx+bDqZ5qd5z428Cw80IaToxb9v4FRSPQ+W6ITch nmzA== Received: by 10.50.37.135 with SMTP id y7mr8069032igj.36.1349161940170; Tue, 02 Oct 2012 00:12:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.82.140 with HTTP; Tue, 2 Oct 2012 00:11:59 -0700 (PDT) In-Reply-To: <20121002070739.23795.46412.idtracker@ietfa.amsl.com> References: <20121002070739.23795.46412.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Tue, 2 Oct 2012 16:11:59 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=f46d04446b153038eb04cb0e3ef3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm3Nf2YqP9ZwhL+rNq52iyhXCt92+vKfTr3YiLGHrxYAwj3SsYc7zwiW/HqD4hAlCbudxBy6iKNTOzOSzQ7yDUe5lctjBrprnWHnCB+aJ2Wz8GldPy9D7gLC7MMNFFHzwK7NUxZcKuZ/uvI4QZK6NVw5ialnC0/bZlKHksTS6WBhlSx2NhDstSiAA6GNJ1cCIN1jbmQ Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-07.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, 02 Oct 2012 07:12:23 -0000 --f46d04446b153038eb04cb0e3ef3 Content-Type: text/plain; charset=ISO-8859-1 Hi all, -07 contains several semantic changes. Semantic change - added per-message extra cost to quota consumption -- http://www.ietf.org/mail-archive/web/hybi/current/msg09820.html - fail the Physical Connection for bad Enc value and invalid handshake -- we're using delta-encoding. so, we cannot keep physical connection healthy ignoring invalid AddChannelRequest/Response -- http://www.ietf.org/mail-archive/web/hybi/current/msg09834.html - added a text about send quota overflow -- http://www.ietf.org/mail-archive/web/hybi/current/msg09834.html - [bug fix] section 7: data frame with an opcode other than "binary frame" -> data message other than "binary" -- continuation frame was disallowed by mistake - [rollback] exchange "Connection" header in AddChannelRequest/Response since it might contain some tokens other than Upgrade -- keep the others (Sec-WebSocket-Accept, Sec-WebSocket-Key, Upgrade, Sec-WebSocket-Version) omitted in AddChannelRequest/Response Non semantic change - named F bits -- F bit in AddChannelResponse is "failure bit" -- F bit in NewChannelSlot is "fallback bit" - clarified that an endpoint doesn't have to send DropChannel following AddChannelResponse with F bit set FYI, recent changes on multiplexing draft are made according to our experience in implementing it on pywebsocket. Thanks Takeshi On Tue, Oct 2, 2012 at 4:07 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 : A Multiplexing Extension for WebSockets > Author(s) : John A. Tamplin > Takeshi Yoshino > Filename : draft-ietf-hybi-websocket-multiplexing-07.txt > Pages : 41 > Date : 2012-10-02 > > Abstract: > The WebSocket Protocol [RFC6455] requires a new transport connection > for every WebSocket connection. This presents a scalability problem > when many clients connect to the same server, and is made worse by > having multiple clients running in different tabs of the same user > agent. This extension provides a way for separate logical WebSocket > connections to share an underlying transport connection. > > 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-websocket-multiplexing > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-multiplexing-07 > > > 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 > --f46d04446b153038eb04cb0e3ef3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

-07 contains several semantic changes= .

Semantic change
- added per-message ex= tra cost to quota consumption
- fail the Physical Connection for bad Enc value and invalid handshake=
-- we're using delta-encoding. so, we cannot keep physical c= onnection healthy ignoring invalid AddChannelRequest/Response
--=A0http://www.ietf.org/mail-archive/web/hybi/current/msg09834.html
- added a text about send quota overflow
- [bug fix] section 7: data frame with an opcode other than "bina= ry frame" -> data message other than "binary"
-= - continuation frame was disallowed by mistake
- [rollback] excha= nge "Connection" header in AddChannelRequest/Response since it mi= ght contain some tokens other than Upgrade
-- keep the others (Sec-WebSocket-Accept, Sec-WebSocket-Key, Upgrade, = Sec-WebSocket-Version) omitted in AddChannelRequest/Response

=
Non semantic change
- named F bits
-- F bit = in AddChannelResponse is "failure bit"
-- F bit in NewChannelSlot is "fallback bit"
- cla= rified that an endpoint doesn't have to send DropChannel following AddC= hannelResponse with F bit set

FYI, recent changes = on multiplexing draft are made according to our experience in implementing = it on pywebsocket.

Thanks
Takeshi


On Tue, Oct 2, 2012 at 4:07 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 : A Multiplexing Extension for We= bSockets
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : John A. Tamplin
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Takeshi Yoshino
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-hybi-websocket-multipl= exing-07.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 41
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-02

Abstract:
=A0 =A0The WebSocket Protocol [RFC6455] requires a new transport connection=
=A0 =A0for every WebSocket connection. =A0This presents a scalability probl= em
=A0 =A0when many clients connect to the same server, and is made worse by =A0 =A0having multiple clients running in different tabs of the same user =A0 =A0agent. =A0This extension provides a way for separate logical WebSock= et
=A0 =A0connections to share an underlying transport connection.

=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= -websocket-multiplexing

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-hybi-websocke= t-multiplexing-07

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


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

--f46d04446b153038eb04cb0e3ef3-- From tyoshino@google.com Thu Oct 4 19:17:44 2012 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 AECF91F0C44 for ; Thu, 4 Oct 2012 19:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.716 X-Spam-Level: X-Spam-Status: No, score=-102.716 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWABMxYC3Fnf for ; Thu, 4 Oct 2012 19:17:44 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 104151F041F for ; Thu, 4 Oct 2012 19:17:42 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so2999920iec.31 for ; Thu, 04 Oct 2012 19:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=FtIwNzPk48N1yOxJEQU98JXLaxWsU1S4E9YxsMORP18=; b=gj/MIRC4uP6hqPN/ie9zyyq3RznU3bMcgk4f6Gg0E9hJp6LVzGRv3SRa0gzgLw6uGq 8mblWqpGwWpqvIgqGW5LHJfWkk/tA3hKNmTfuzxlmAShI3P1CexCtN09i56rcRp8+iW3 onVjHYrvRFiy/Rc7jinpTC00mXfleDtPj4xoUsW+9LtajX9UAqBnJG4+ldNeS0Zymwig 10jpsGSmPq7gVxIUaGE8OqchKDXYfrSJgTeCpVHA/BgkHWC4z43tLYzkbfvK0L8PFw48 kOZAAyFXv7ObPQ3u+GopYxJt+vHhJS8YTICCvUcPoYQK3SKO5JJGVdBqMxOQuoOAfY2w 98uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=FtIwNzPk48N1yOxJEQU98JXLaxWsU1S4E9YxsMORP18=; b=BDd9DtwsMrb/3OrCamywOqq2qGL5xxEOGd890dbZTmKmvu05ww5Zk9XaIFbB0UDlX6 MLPOgQ670OeSSDruzgSIjHIN5Xe8IJtTwE/WwArJWU1Xf1amGAzTZLecDzZbMeWwUV76 qGe5dkbqFbexcK1LqSws/OwzTyRcDSDVSrrvNprk+DEZfRwsPRj/JaSEr+W0Ko0NpVfv g0vgqWwe0rdtyXfx2ofT3baHZmpDh8xJEvl7t1oFxKIsPsYymh7ocQlZbcDPFMHpvtK2 IhHQ1dOsPogk69OVqtANoytCP8v9slyQcJzfVx5eFXofWVxCjOpCO2NUCL0ihX8Q3NU8 b94g== Received: by 10.50.46.134 with SMTP id v6mr7290971igm.55.1349403462478; Thu, 04 Oct 2012 19:17:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.82.140 with HTTP; Thu, 4 Oct 2012 19:17:22 -0700 (PDT) From: Takeshi Yoshino Date: Fri, 5 Oct 2012 11:17:22 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae9340f530a2bf504cb467a4b X-System-Of-Record: true X-Gm-Message-State: ALoCoQkEp8jZ0izD+kJ4yXcbvSjS96gEE+k1tsKl1MTZfWmpEGPXvwG/HqAS1yJdvTI1QADI6jqDdRfG712tpoBVg5UWplmXNXJLgfr3oyRoA+oTc0EMGTYfWcgwfHdV11TzGrtB4H7QjWyUfB4PnHhGyzz/0um2CS/CZsHbT8UJ3MQSCPQR3K7Kv48mRaSshtjrfUBvOGB/ Subject: [hybi] CRIME attack and compression after multiplexing 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, 05 Oct 2012 02:17:44 -0000 --14dae9340f530a2bf504cb467a4b Content-Type: text/plain; charset=ISO-8859-1 If multiplexing and (deflate) compression are applied in this order, WebSocket will be vulnerable to the CRIME attack, I think. Frame stream after multiplexing contains AddChannelRequest blocks and they are compressed by premessage-compress. I'm planning to add texts to the extension specs to disallow deflate after mux. For example Sec-WebSocket-Extensions: mux, permessage-compress; method=deflate must not be used over TLS by UAs like browsers where malicious scripts may run. Different from BEAST, masking doesn't help for this case. Takeshi --14dae9340f530a2bf504cb467a4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If multiplexing and (deflate) compression are=A0applied in this order,= WebSocket will be vulnerable to the CRIME attack, I think.=A0Frame stream = after multiplexing contains AddChannelRequest blocks and they are compresse= d by premessage-compress.

I'm planning to add texts to the extension specs to= disallow deflate after mux. For example
Sec-WebSocket-Extensions= : mux, permessage-compress; method=3Ddeflate
must not be used=A0o= ver TLS=A0by UAs like browsers=A0where malicious scripts may run.

Different from BEAST, masking doesn't help for this= case.

Takeshi
--14dae9340f530a2bf504cb467a4b-- From internet-drafts@ietf.org Wed Oct 10 02:29:10 2012 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 33A5221F86DE; Wed, 10 Oct 2012 02:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLjlvZb5inNk; Wed, 10 Oct 2012 02:29:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E38F21F84FF; Wed, 10 Oct 2012 02:29:09 -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.34 Message-ID: <20121010092909.3656.83823.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2012 02:29:09 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.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, 10 Oct 2012 09:29:10 -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 : A Multiplexing Extension for WebSockets Author(s) : John A. Tamplin Takeshi Yoshino Filename : draft-ietf-hybi-websocket-multiplexing-08.txt Pages : 41 Date : 2012-10-10 Abstract: The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. 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-websocket-multiplexing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-websocket-multiplexing-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Wed Oct 10 02:33:26 2012 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 6C9B121F84B9 for ; Wed, 10 Oct 2012 02:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSt8L4LDt75t for ; Wed, 10 Oct 2012 02:33:25 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AAFF721F845A for ; Wed, 10 Oct 2012 02:33:25 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so256315iad.31 for ; Wed, 10 Oct 2012 02:33:25 -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:x-system-of-record; bh=E3MjKTrc9ZYCFtzFPpTwovVm9VSNtN9bzsZIfaJ1p5M=; b=F+jD78iiSrpnTFvBbx5czRrOMvkrkKYZO9rf25KGBmlfz/b/SF+jab6nUQsQJp2gQA rYHsGQ4leTkUzCSJmaF/1HaKZeg4gcEvcuvxZC21ReIVOtB6VuVGn11KfaNowgNm0xJB PPb+0DSXhJ3JxlHT66ZKK6Aa3MjJyXw7545W/T9MxvJbQmPmXWHzkdYlWnBJKg+D98pw BZv7bCZNpfwo0RmiloR9WMC6wLlKFv5nqdQPkzBhEWIVZfYhbE/y+EUZt5u7H9TVq8mQ IDpAzseLL6O/Ra8karxipy0O3w+l/ZFGb9jhziLDgY0B5x4QktKMo0gHP0S0fhvdRGGT NZTA== 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-system-of-record:x-gm-message-state; bh=E3MjKTrc9ZYCFtzFPpTwovVm9VSNtN9bzsZIfaJ1p5M=; b=onwfvS2yBYGmmKtsSHcMyeYuMfo677ObffFYaRJn0hHRFl9fkpCnaa2rooB4Zs0dnq Y6p2EGzKOCWIfyfzRUTbqBFgqF+7AkEEBShvHM4OUorMf+2PqSSQaw0zwKZkSRzOA4au cmIuFuf8JJR5h9fJ016JREeD9mZaIRw/1Qzry6mr0F0JOQiw2umZ1IDfAp4eWbk6BYp0 QPESxpKq6kbQ12Ky3moIqh4H1ey5J81JByI5QD62wDbYbsjLU+hL+HTZbsaTof7Z6L2D RbhP8IRVedBsxFwb25CxJezStK45B4UqP09xvMgZSxZkBSgAyEsbnf4CpOBJV/LMjEaW o8VQ== Received: by 10.42.156.1 with SMTP id x1mr17786742icw.51.1349861605128; Wed, 10 Oct 2012 02:33:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Wed, 10 Oct 2012 02:33:04 -0700 (PDT) In-Reply-To: <20121010092909.3656.83823.idtracker@ietfa.amsl.com> References: <20121010092909.3656.83823.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Wed, 10 Oct 2012 18:33:04 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=90e6ba10b0877839cb04cbb125a6 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl+r7em1j2g6DduYCBZXCj11hwSAznNlF8xvo8+N4kWglcaU4CrtsJJ1QniapRbHanCdoJjwvbCPDOGKPoCCq7cRfDw1ZRXRaipIQTDHEXEjjERYnSpzq7ne0jPXiB6/oj6y/uJtu7caJN7QANU7z67klBssZZkQVGBXXFn4DpLkHZp3BjZLphATfypfWa+qS2V2ize Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.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, 10 Oct 2012 09:33:26 -0000 --90e6ba10b0877839cb04cbb125a6 Content-Type: text/plain; charset=ISO-8859-1 Disallowed use of "mux, permessage-compress; method=deflate" (compress output of multiplexing extension) over TLS. http://www.ietf.org/mail-archive/web/hybi/current/msg09846.html "permessage-compress; method=deflate, mux" (compress each multiplexed connection, and then multiplex) is still considered to be safe. Thanks Takeshi On Wed, Oct 10, 2012 at 6:29 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 : A Multiplexing Extension for WebSockets > Author(s) : John A. Tamplin > Takeshi Yoshino > Filename : draft-ietf-hybi-websocket-multiplexing-08.txt > Pages : 41 > Date : 2012-10-10 > > Abstract: > The WebSocket Protocol [RFC6455] requires a new transport connection > for every WebSocket connection. This presents a scalability problem > when many clients connect to the same server, and is made worse by > having multiple clients running in different tabs of the same user > agent. This extension provides a way for separate logical WebSocket > connections to share an underlying transport connection. > > 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-websocket-multiplexing > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-multiplexing-08 > > > 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 > --90e6ba10b0877839cb04cbb125a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Disallowed use of
"mux, permessage-compress; method=3Dd= eflate" (compress output of multiplexing extension)
over TLS= .


"permessage-compress; method=3Ddeflate, mux&= quot; (compress each multiplexed connection, and then multiplex)
= is still considered to be safe.

Thanks
Takeshi


On Wed, Oct 10, 2012 at 6:29 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 : A Multiplexing Extension for We= bSockets
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : John A. Tamplin
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Takeshi Yoshino
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-hybi-websocket-multipl= exing-08.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 41
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-10

Abstract:
=A0 =A0The WebSocket Protocol [RFC6455] requires a new transport connection=
=A0 =A0for every WebSocket connection. =A0This presents a scalability probl= em
=A0 =A0when many clients connect to the same server, and is made worse by =A0 =A0having multiple clients running in different tabs of the same user =A0 =A0agent. =A0This extension provides a way for separate logical WebSock= et
=A0 =A0connections to share an underlying transport connection.

=A0 =A0Please 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= -websocket-multiplexing

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-hybi-websocke= t-multiplexing-08

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


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

--90e6ba10b0877839cb04cbb125a6-- From tobias.oberstein@tavendo.de Wed Oct 10 03:34:11 2012 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 1710F21F86D4 for ; Wed, 10 Oct 2012 03:34:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjJvK7mc3oht for ; Wed, 10 Oct 2012 03:34:10 -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 7BA1C21F86D1 for ; Wed, 10 Oct 2012 03:34:10 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.219]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Wed, 10 Oct 2012 03:34:09 -0700 From: Tobias Oberstein To: Takeshi Yoshino , "hybi@ietf.org" Date: Wed, 10 Oct 2012 03:34:08 -0700 Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.txt Thread-Index: Ac2mylIYRtPVxt1rQpaTmjMy42LBfAACBoRA Message-ID: <634914A010D0B943A035D226786325D4339129C5B6@EXVMBX020-12.exch020.serverdata.net> References: <20121010092909.3656.83823.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-websocket-multiplexing-08.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, 10 Oct 2012 10:34:11 -0000 Hello Takeshi, is there any work ongoing or planned to allow HTTP2 and WebSocket traffic t= o share a single WS connection multiplexed via this extension? Do you have comments regarding: https://docs.google.com/document/d/1zUEFzz7NCls3Yms8hXxY4wGXJ3EEvoZc3GihrqP= QcM0/edit?pli=3D1 "There are other efforts to introduce multiplexing for WebSocket. Takeshi p= roposed a mux extension for WebSocket [MUX]. The proposal aims to realize e= ffective multiplexing layering for WebSockets with minimum overheads, but i= t doesn't consider to share the same connection with HTTP. Thus, client nee= ds two connections for HTTP and WebSocket. Gabriel proposed a plan [SPEEDMO= BILITY] to use WebSocket for HTTP/2.0. There, SPDY like multiplexing is bui= lt on the top of WebSocket. But it doesn't consider to multiplex WebSocket = connections for now." Cheers, Tobias From tyoshino@google.com Wed Oct 10 04:04:08 2012 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 0A30921F86B5 for ; Wed, 10 Oct 2012 04:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.764 X-Spam-Level: X-Spam-Status: No, score=-102.764 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSUc4ZI5ZqfJ for ; Wed, 10 Oct 2012 04:04:07 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9E3621F86A8 for ; Wed, 10 Oct 2012 04:04:05 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so314906iad.31 for ; Wed, 10 Oct 2012 04:04:05 -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:x-system-of-record; bh=c2np3g0QAfedpx8ypAisLa6PL2nYSc0f10SO2mzF4NE=; b=cFoirwZWFIAwWi7UmCyYW6brDnzJ9XPgLZ73w3EIbOe7XntFtMcDyUZTJyB9VWqDhV iRo7i8ZW4r6oIv/x1ml41WCnniVaOPqMh5jwuRL7Eelze4SyzFBtvJSkL3ebpKc+V8Tl 5ZkU/GlCSBdz9elpVMwzOWOztA6HFplkV+dCEO6M76ZUlUXL2k1u3BwzJcnV8rQl05gG t4fkYA2GPXKdYqwo7PV9qJH/JY3MODmUCWB9qXzRmGjEiHe664Yq66tfHGL/ZpyL58NE WjVTbXHmaHu+cyOY9VjK8+WtCJKM7mrpTG8FT68rt7ZckUDqEt0gSBvF92bOofrt+sG2 hatA== 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-system-of-record:x-gm-message-state; bh=c2np3g0QAfedpx8ypAisLa6PL2nYSc0f10SO2mzF4NE=; b=cO6NwrkdGC/UL+hEyye63J668CwpzsINZWeK9r7ldSgwXLBaZsUSpkkKS1yznMF3Sa O9cGfW/mItvF0+gbCMlVn/YZ+gH2X3aj6Bs04dBEhDQTMF53mloNxw2wOn+J1vnuUaci 3oxlrn4oPFN6NTTaM+qCafIMucsU6Gq3BwJeTEebz1GUqOj0phKNVXUAPLR1eqgwPya9 UJial7Pzlmvbkb4GPqe4YQo6HPSAlWyHJa8VEO2vrCBAWBk5kgpiaZ0TNviiMYHI6jDv k4kd0pH1c0pShUOHl8zgYCLgKzr5Z4qiLeR0xXkiN7REFGQwX/aw5WOMm19D2KlVI0d1 G8Ew== Received: by 10.50.219.129 with SMTP id po1mr4764766igc.35.1349867045223; Wed, 10 Oct 2012 04:04:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Wed, 10 Oct 2012 04:03:44 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4339129C5B6@EXVMBX020-12.exch020.serverdata.net> References: <20121010092909.3656.83823.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4339129C5B6@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Wed, 10 Oct 2012 20:03:44 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=14dae93410cbb97cdc04cbb26974 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmcX2fOUmEv80gX7Ss8lqGwL4jJ3vwp3FCM4/087d+mpVRAAbSHTAWU0UijAS4K+ozUACwkYg6zPVX6OWGUcOQeMNxuWkt2ZnWK1NDw8ZJv99gasDkkwU0x3NGSISAXgZ3AXUvnCLZLfrgFIkV2kHeEZ8PXUULYr4NC6CcmSvMvtLlcv30CrXY21pLBb9T63yYmBCd1 Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.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, 10 Oct 2012 11:04:08 -0000 --14dae93410cbb97cdc04cbb26974 Content-Type: text/plain; charset=ISO-8859-1 Hello Tobias, On Wed, Oct 10, 2012 at 7:34 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > Hello Takeshi, > > is there any work ongoing or planned to allow HTTP2 and WebSocket traffic > to share a single WS connection multiplexed via this extension? > I kicked it around and summarized my thoughts in a few posts to HyBi: http://www.ietf.org/mail-archive/web/hybi/current/msg09777.html http://www.ietf.org/mail-archive/web/hybi/current/msg09801.html http://www.ietf.org/proceedings/84/slides/slides-84-hybi-2.pdf last slide That's all I have. I still think it's not bad to use WebSocket + multiplexing extension for HTTP/2.0 transport, but now am focusing on making multiplexing available for WebSocket. > Do you have comments regarding: > > > https://docs.google.com/document/d/1zUEFzz7NCls3Yms8hXxY4wGXJ3EEvoZc3GihrqPQcM0/edit?pli=1 > > "There are other efforts to introduce multiplexing for WebSocket. Takeshi > proposed a mux extension for WebSocket [MUX]. The proposal aims to realize > effective multiplexing layering for WebSockets with minimum overheads, but > it doesn't consider to share the same connection with HTTP. Thus, client > needs two connections for HTTP and WebSocket. Gabriel proposed a plan > [SPEEDMOBILITY] to use WebSocket for HTTP/2.0. There, SPDY like > multiplexing is built on the top of WebSocket. But it doesn't consider to > multiplex WebSocket connections for now." --14dae93410cbb97cdc04cbb26974 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Tobias,

On Wed, Oct 10, 2012 at 7:= 34 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
Hello Takeshi,

is there any work ongoing or planned to allow HTTP2 and WebSocket traffic t= o share a single WS connection multiplexed via this extension?

I kicked it around and summarized my thoughts in a = few posts to HyBi:
http://www.ietf.org/mail-archive/web/hybi/current/msg09777.html

Do you have comments regarding:

https://docs.google.com/doc= ument/d/1zUEFzz7NCls3Yms8hXxY4wGXJ3EEvoZc3GihrqPQcM0/edit?pli=3D1

"There are other efforts to introduce multiplexing for WebSocket. Take= shi proposed a mux extension for WebSocket [MUX]. The proposal aims to real= ize effective multiplexing layering for WebSockets with minimum overheads, = but it doesn't consider to share the same connection with HTTP. Thus, c= lient needs two connections for HTTP and WebSocket. Gabriel proposed a plan= [SPEEDMOBILITY] to use WebSocket for HTTP/2.0. There, SPDY like multiplexi= ng is built on the top of WebSocket. But it doesn't consider to multipl= ex WebSocket connections for now."
=A0
--14dae93410cbb97cdc04cbb26974-- From tyoshino@google.com Wed Oct 10 05:35:35 2012 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 CC37F21F86D4 for ; Wed, 10 Oct 2012 05:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRvfCOqH2g2j for ; Wed, 10 Oct 2012 05:35:35 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B568321F86CE for ; Wed, 10 Oct 2012 05:35:34 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so393219lam.31 for ; Wed, 10 Oct 2012 05:35:33 -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:x-system-of-record; bh=xUhHVt23HmMWuY076XP1M63lytlMD/8mMV1tvdpVnRE=; b=Vfkkn/UVLBWN9SwQ++ACCVMp7CTo9zZlrhoH3SCtikVX5lG6SMJukpUJd09sezS15F ufKcWA/v9jfvTXDvT6E/8f/q60zSbPVCwgxThIo38iMFGO5j5COkLpdRVtGC9k6UrcCa rZv0wYPSoo0b0EQzXmt2Il4XN1jewTgSUYl1DfXUjaRkIlvVIEkEBmZ48en1+3duwW+K jfgS00qU7sihBicKC7yRA1+u8FFDH3CMhwlVmqUePos3P3RlaTP6yBggpGG9Tpv07nyV HU1J3SiPDPbSjpZ/jsh1Ol6kXRGNpgzuWKcMB9Mr7jkcdkMndK2n4CbDFvW2q7KL4Xhl 4tKg== 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-system-of-record:x-gm-message-state; bh=xUhHVt23HmMWuY076XP1M63lytlMD/8mMV1tvdpVnRE=; b=fEkcG7x0clJodExXIHKlTLvp+dnfOIxRTo7Vpr749ZPHdaAYr8Cc7sTGa1XBCy2t6u twVQaZ9LmnSrV67cr81MWZG9AnihSxPTgd0OnFqY6DLgRijKFCViJ37lkRAArYI+0pW3 lNXpofglrf3rWASbv7U+qvdldilb5YMF1owZICYk/fF0SpF518+UV8qAZIqbSB6OBHXd vYkv33yuoQ1lKYpgmDl5oRNszIyQK3HHcDSeG79RY0AU3lDlEUiby4XJVEEmyHy4yhHS 1n326Xb1Fc/M4uzrYeaspBYvqHZ3/jlDjWFFuKJCKIidIFOuFTF5meUt1FQajsfiu6PT Ltsg== Received: by 10.152.146.101 with SMTP id tb5mr15962008lab.44.1349872533352; Wed, 10 Oct 2012 05:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.71.103 with HTTP; Wed, 10 Oct 2012 05:35:13 -0700 (PDT) In-Reply-To: <000601cda6de$1d520f00$57f62d00$@noemax.com> References: <20121010092909.3656.83823.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4339129C5B6@EXVMBX020-12.exch020.serverdata.net> <000601cda6de$1d520f00$57f62d00$@noemax.com> From: Takeshi Yoshino Date: Wed, 10 Oct 2012 21:35:13 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=e89a8f2348b3d7b0e004cbb3b031 X-System-Of-Record: true X-Gm-Message-State: ALoCoQldojrUcSLpgDwln0Sx3I9AZWVK5s4BguPEReDAXv/Q0UbIOFaJoO4QSWZEx1op4owiFzDlGWFs2mNM2+NQeL9mprbHsBijIEl0gR443aBejwDyA+niohzdQn6XImrZaAtQ7Ng3v5CbV4zE5hIDinRF+SnGFhCILqEz2Wpb7+lzXt1RQKVcFf4CopvCDkcLAeaIqwUA Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.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, 10 Oct 2012 12:35:35 -0000 --e89a8f2348b3d7b0e004cbb3b031 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 10, 2012 at 8:55 PM, Arman Djusupov wrote: > Back in July I had made the following comment.... > > "If we would envelope the entire traffic produced by the logical channel > (complete frames including headers) then we would not have this problem, > Which problem? > plus WS mux would be able to multiplex any protocol (e.g. SPDY) and not > only > WebSocket frames." > What do you mean by "multiplex SPDY"? One of SPDY's core concepts is delta-compression on headers. It needs involvement of multiplexing. Running full SPDY on a logical channel of WebSocket mux sounds not so good because of duplication of multiplexing. Once we - add some extension parameters to mux to enable capable protocol negotiation - add "protocol" header or something to the AddChannelRequest to pass the protocol of the logical channel - include nothing else in the handshake portion of the AddChannelRequest - define how quota is consumed for the protocol (maybe, just equals to transferred raw bytes) it can envelope the entire traffic of any protocol transparently. WebSocket mux 2.0 may support such a mode. However, for WebSocket (and any other message-oriented protocol), this method duplicates length info. That's not the best thing to do. > I still think that it would be beneficial to make the protocol used by the > logical channel transparent to the mux, so that mux can be used for > multiplexing any protocol. > --e89a8f2348b3d7b0e004cbb3b031 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 10, 2012 at 8:55 PM, Arman Djusupov = <arman@noemax.com> wrote:
Back in July I had made the following comment....

"If we would envelope the entire traffic produced by the logical chann= el
(complete frames including headers) then we would not have this problem,

Which problem?
=A0
plus WS mux would be able to multiplex any protocol (e.g. SPDY) and not onl= y
WebSocket frames."

What do you mea= n by "multiplex SPDY"? One of SPDY's core concepts is delta-c= ompression on headers. It needs involvement of multiplexing.

Running full SPDY on a logical channel of WebSocket mux soun= ds not so good because of duplication of multiplexing.

=
Once we
- add some extension parameters to mux to enable cap= able protocol negotiation
- add "protocol" header or something to the AddChannelReques= t to pass the protocol of the logical channel
- include nothing e= lse in the handshake portion of the AddChannelRequest
- define ho= w quota is consumed for the protocol (maybe, just equals to transferred raw= bytes)
it can envelope the entire traffic of any protocol transparently.

WebSocket mux 2.0 may support such a mode.
<= br>
However, for WebSocket (and any other message-oriented protoc= ol), this method duplicates length info. That's not the best thing to d= o.
=A0
I still think that it would be= beneficial to make the protocol used by the
logical channel transparent to the mux, so that mux can be used for
multiplexing any protocol.
--e89a8f2348b3d7b0e004cbb3b031-- From SRS0+2a2fdd582373e458=IH=noemax.com=arman@noemax.com Wed Oct 10 07:04:54 2012 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 EA95621F86A4 for ; Wed, 10 Oct 2012 07:04:54 -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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJglflkkvDYg for ; Wed, 10 Oct 2012 07:04:52 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6766D21F86B2 for ; Wed, 10 Oct 2012 07:04:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1349877895; x=1350482695; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=uAjZc9a0B76zNpKthXa2nn3l4K0=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=Oin1jdv3Ks0x2pdVWGMJsOIAG9uW2AinChjN2c9iDr2+d/4tUyMkgjm23sWxZZy6spzuuEZw3uT05RN2kTnHxYAMTx0vMpF8yV07/hEMtEtLLWpbVcUYnzl3y/fnx/Bt7MtgPovZAMorNB8o2mO9QkrkUf5au7EfpbrHfzoW4wA= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.3) with ASMTP (SSL) id UYO00754; Wed, 10 Oct 2012 17:04:54 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <20121010092909.3656.83823.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4339129C5B6@EXVMBX020-12.exch020.serverdata.net> <000601cda6de$1d520f00$57f62d00$@noemax.com> In-Reply-To: Date: Wed, 10 Oct 2012 17:04:38 +0300 Message-ID: <001501cda6f0$32e14b80$98a3e280$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CDA709.582E8380" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKu7vlx8cDeHauGs2fWB5Gg+Gc1aQKub5i9AgxQ/VcBk4fQ7wHXY9cala7UPGA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.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, 10 Oct 2012 14:09:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0016_01CDA709.582E8380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit See my answer inline. From: Takeshi Yoshino [ mailto:tyoshino@google.com] Sent: Wednesday, October 10, 2012 3:35 PM To: Arman Djusupov Cc: Tobias Oberstein; hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.txt Which problem? I was just quoting my old post, it was concerning some of the flow control quota problems we had with 0 bytes frames. plus WS mux would be able to multiplex any protocol (e.g. SPDY) and not only WebSocket frames." What do you mean by "multiplex SPDY"? One of SPDY's core concepts is delta-compression on headers. It needs involvement of multiplexing. Delta compressing headers can be performed even with a single logical channel, SPDY can delta compress headers of subsequent messages sent over the same logical connection using the state formed by compressing previous headers. It defines an initial dictionary for DEFLATE that includes the most common headers, so this dictionary does not need to be shared between logical channels to give a good compression ratio. There are also other problems that would have to be addressed for SPDY to work with WS mux (one I can think of is opening channels in both directions, and another the reuse of an allocated WS logical channel for a new SPDY stream with implicit allocation of SDPY stream ID on both sides for every new outbound/inbound message). Running full SPDY on a logical channel of WebSocket mux sounds not so good because of duplication of multiplexing. In such a scenario the SPDY frame should be stripped of the stream ID related information and rely on the WS logical channels. WS can be multiplexed over SPDY and SPDY can be multiplexed over WS. Since WS does not require TLS/NPN which is major obstacle for adopting SPDY, I think it's preferable to have SPDY use WS mux, rather than other way around. Once we - add some extension parameters to mux to enable capable protocol negotiation - add "protocol" header or something to the AddChannelRequest to pass the protocol of the logical channel - include nothing else in the handshake portion of the AddChannelRequest - define how quota is consumed for the protocol (maybe, just equals to transferred raw bytes) it can envelope the entire traffic of any protocol transparently. I think the quota should be equal to the number of raw bytes tunneled. WebSocket mux 2.0 may support such a mode. However, for WebSocket (and any other message-oriented protocol), this method duplicates length info. That's not the best thing to do. When we treat the encapsulated traffic as a transparent duplex stream of bytes and the WS frame boundaries do not match and the underlying protocol frames, it's hard to say that the length is getting duplicated. What we have is an additional expense for tunneling a connection. If the underlying protocol is transparent there is nothing that can be done to prevent this. Otherwise we will have to write a mux extension for each transport that has to be multiplexed. With best regards, Arman ------=_NextPart_000_0016_01CDA709.582E8380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See my answer inline.

 

From: Takeshi = Yoshino [mailto:tyos= hino@google.com] =
Sent: Wednesday, October 10, 2012 3:35 PM
To: Arman = Djusupov
Cc: Tobias Oberstein; hybi@ietf.o= rg
Subj= ect: Re: [hybi] I-D Action: = draft-ietf-hybi-websocket-multiplexing-08.txt

 

Which = problem?

 

I was just quoting my old post, it was concerning some of the flow = control quota problems we had with 0 bytes = frames.

 

plus WS mux = would be able to multiplex any protocol (e.g. SPDY) and not = only
WebSocket frames."

 

What do you = mean by "multiplex SPDY"? One of SPDY's core concepts is = delta-compression on headers. It needs involvement of = multiplexing.

 

Delta compressing headers can be performed even with a single logical = channel, SPDY can delta compress headers of subsequent messages sent = over the same logical connection using the state formed by compressing = previous headers. It defines an initial dictionary for DEFLATE that = includes the most common headers, so this dictionary does not need to be = shared between logical channels to give a good compression ratio. There = are also other problems that would have to be addressed for SPDY to work = with WS mux (one I can think of is opening channels in both directions, = and another the reuse of an allocated WS logical channel for a new SPDY = stream with implicit allocation of SDPY stream ID on both sides for = every new outbound/inbound message).

 

Running full = SPDY on a logical channel of WebSocket mux sounds not so good because of = duplication of multiplexing.

 

In such a scenario the SPDY frame should be stripped of the stream ID = related information and rely on the WS logical channels. =

 

WS can be multiplexed over SPDY and SPDY can be multiplexed over WS. = Since WS does not require TLS/NPN which is major obstacle for adopting = SPDY, I think it’s preferable to have SPDY use WS mux, rather than = other way around.

 

Once = we

- add some extension parameters to = mux to enable capable protocol negotiation

- add "protocol" header or something to the = AddChannelRequest to pass the protocol of the logical = channel

- include nothing else in the = handshake portion of the AddChannelRequest

- define how quota is consumed for the protocol = (maybe, just equals to transferred raw bytes)

it can envelope the entire = traffic of any protocol transparently.

 

I think the quota should be equal to the number of raw bytes = tunneled.

 

WebSocket mux 2.0 may support such a = mode.

 

However, for WebSocket (and any other message-oriented = protocol), this method duplicates length info. That's not the best thing = to do.

 

When we treat the encapsulated traffic as a transparent duplex stream = of bytes and the WS frame boundaries do not match and the underlying = protocol frames, it’s hard to say that the length is getting = duplicated. What we have is an additional expense for tunneling a = connection. If the underlying protocol is transparent there is nothing = that can be done to prevent this. 

 

Otherwise we will have to write a mux extension for each transport = that has to be multiplexed.

 

With best regards,

Arman

 

------=_NextPart_000_0016_01CDA709.582E8380-- From tyoshino@google.com Wed Oct 10 20:41:37 2012 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 5080E11E80E5 for ; Wed, 10 Oct 2012 20:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56VSUr534j6P for ; Wed, 10 Oct 2012 20:41:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA1EF11E8099 for ; Wed, 10 Oct 2012 20:41:35 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1067321lbo.31 for ; Wed, 10 Oct 2012 20:41:34 -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:x-system-of-record; bh=8qmf9FRHGrILBsfNyvMeu4l6WpaWwRwkFMNcgmAbJfw=; b=KE+Poqc0QGEzGKDR4v+LYthU0C3dYe3I4Xlv3e/5IoGbAC3ql21+hU5m5gLXSd2cXf 6aR4KTzUEWRdFX9DzNEip+up7xkE2WMaBX0Sc3k5xM8Xn7JCWLCC5diZSmvHnRzueONF XLe8pT1yR2751ZvdAaqe8WerRyEQfIhEMt/zFR3jSyjzTkSkSVi4YLOIgQQb0ESb2v6c mlnjSXx5POpkM9aXdA5yl4nD1UPtx3ZtWpjtGUkFZp8YpxLMSPLmMyeFdqQvZhlEZoIq SP3LuV1dDcXBucP0vlsZ225weLBcPdDyXsP4VAwXn2OYSQLOpWfTXtDQ0gRZrVpHf9Ho pq4g== 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-system-of-record:x-gm-message-state; bh=8qmf9FRHGrILBsfNyvMeu4l6WpaWwRwkFMNcgmAbJfw=; b=Nwg3t0j/HoRWeCLadcLD2SLfMPl+BNu8Oege8KjKU++IHFwnpBLEbdbOxORO1suD87 1ZhgfzXBfnoz/PhneH7vvnKIpfLS0sme59nuc7f0lLusPol05ffkTMl4I8dpUyd7qhLp Pv+zJsX8NssNIJcBoS2ykNShRm3roiCNvUzCcavZnzZ8uSL2DFYCUBDy/Qex/Akrqcd8 oRhwjnQf6Zd/h/1yXIoctDrZ31iaVCRb04tDaQNMpRs5bT+cryj9E1v8un1oDOQRdtkT 0ffmxim8InnQ7vrdGba5J2iuJwCfmkwfQihqpqF3yHlCqWXzxl01RO0nd/GC/yz3+Rt9 hdHA== Received: by 10.152.106.212 with SMTP id gw20mr18949854lab.8.1349926894687; Wed, 10 Oct 2012 20:41:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.71.103 with HTTP; Wed, 10 Oct 2012 20:41:14 -0700 (PDT) In-Reply-To: <001501cda6f0$32e14b80$98a3e280$@noemax.com> References: <20121010092909.3656.83823.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4339129C5B6@EXVMBX020-12.exch020.serverdata.net> <000601cda6de$1d520f00$57f62d00$@noemax.com> <001501cda6f0$32e14b80$98a3e280$@noemax.com> From: Takeshi Yoshino Date: Thu, 11 Oct 2012 12:41:14 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=f46d0420a69507d42d04cbc05990 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlExnb7uNm5lOZT/MyLgdGuUmMz01RMV2UdSo402ok41WTdAmO/tl4FjEmZp0S+hsCd+PP+iF7Y1SG+lnDymba1ocril8b3YpdiPfojYc8qukOsv6pcnZzrWyb/QxllEiY6QedNo4MeAh6xwLjT8/rwtNIN4NRdA7HnOLdlqOiBAOfdotycteeSwJ7CPLc5Hb3MhJPS Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.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, 11 Oct 2012 03:41:37 -0000 --f46d0420a69507d42d04cbc05990 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Oct 10, 2012 at 11:04 PM, Arman Djusupov wrote: > Which problem? > > ** ** > > I was just quoting my old post, it was concerning some of the flow contro= l > quota problems we had with 0 bytes frames.**** > > I see. > plus WS mux would be able to multiplex any protocol (e.g. SPDY) and not > only > WebSocket frames."**** > > ** ** > > What do you mean by "multiplex SPDY"? One of SPDY's core concepts is > delta-compression on headers. It needs involvement of multiplexing.**** > > ** ** > > Delta compressing headers can be performed even with a single logical > channel, SPDY can delta compress headers of subsequent messages sent over > the same logical connection using the state formed by compressing previou= s > headers. It defines an initial dictionary for DEFLATE that includes the > most common headers, so this dictionary does not need to be shared betwee= n > logical channels to give a good compression ratio. > > So your idea is to allocate N WS logical channels where N is concurrency and reuse established but unused WS sessions for next SPDY stream? SPDY designers really care about initial latency. Your method seems to limit power of multiplexing+delta-compression for the first request. When UA loads hundreds of resources for the first HTML document, there're not yet hundreds of WS sessions established. All concurrently issued AddChannelRequests need to carry full set of headers. > Once we**** > > - add some extension parameters to mux to enable capable protocol > negotiation**** > > - add "protocol" header or something to the AddChannelRequest to pass the > protocol of the logical channel**** > > - include nothing else in the handshake portion of the AddChannelRequest*= * > ** > > - define how quota is consumed for the protocol (maybe, just equals to > transferred raw bytes)**** > > it can envelope the entire traffic of any protocol transparently.**** > > ** ** > > I think the quota should be equal to the number of raw bytes tunneled. **= * > * > > ** > > Yes. I meant tunneled bytes. > WebSocket mux 2.0 may support such a mode.**** > > ** ** > > However, for WebSocket (and any other message-oriented protocol), this > method duplicates length info. That's not the best thing to do.**** > > ** ** > > When we treat the encapsulated traffic as a transparent duplex stream of > bytes and the WS frame boundaries do not match and the underlying protoco= l > frames, it=92s hard to say that the length is getting duplicated. > > It's also true that we can reduce the extra expense for WebSocket. > What we have is an additional expense for tunneling a connection. If the > underlying protocol is transparent there is nothing that can be done to > prevent this. **** > > ** ** > > Otherwise we will have to write a mux extension for each transport that > has to be multiplexed. > > For example, we can define "raw-" prefix for values used in the protocol field in the AddChannelRequest block which I'm suggested. For raw-xxx protocol, multiplexing extension provides simple tunneling. This way, we don't have to define multiplexing extensions for each protocol. --f46d0420a69507d42d04cbc05990 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 10, 2012 at 11:04 PM, Arman Djusupov= <arman@noemax.com> wrote:

Which problem?

=A0

I was just quoting my old post, it was concer= ning some of the flow control quota problems we had with 0 bytes frames.=

I see.

plus WS mux would be able to multiplex any protocol (e.g.= SPDY) and not only
WebSocket frames."

=A0<= u>

What do you mean by "multiplex SPDY&q= uot;? One of SPDY's core concepts is delta-compression on headers. It n= eeds involvement of multiplexing.

=A0<= /p>

Delta compressin= g headers can be performed even with a single logical channel, SPDY can del= ta compress headers of subsequent messages sent over the same logical conne= ction using the state formed by compressing previous headers.=A0It defines an initial dictionary for DEFLATE that includes the most com= mon headers, so this dictionary does not need to be shared between logical = channels to give a good compression ratio.

So your idea is to allocate N WS logic= al channels where N is concurrency and reuse established but unused WS sess= ions for next SPDY stream?

SPDY designers really c= are about initial latency. Your method seems to limit power of multiplexing= +delta-compression for the first request. When UA loads hundreds of resourc= es for the first HTML document, there're not yet hundreds of WS session= s established. All concurrently issued AddChannelRequests need to carry ful= l set of headers.=A0

Once we

- add some extension parameters to mux to enable capable pro= tocol negotiation

- add "proto= col" header or something to the AddChannelRequest to pass the protocol= of the logical channel

- include nothing else in the handshake portion of t= he AddChannelRequest

- define how q= uota is consumed for the protocol (maybe, just equals to transferred raw by= tes)

it can envelope the entire traffic of any protocol t= ransparently.

=A0

I think the quota s= hould be equal to the number of raw bytes tunneled.

Yes. I meant tunneled bytes.=A0

WebSoc= ket mux 2.0 may support such a mode.

=A0

However,= for WebSocket (and any other message-oriented protocol), this method dupli= cates length info. That's not the best thing to do.

=A0

When we treat the encapsulated traff= ic as a transparent duplex stream of bytes and the WS frame boundaries do n= ot match and the underlying protocol frames, it=92s hard to say that the le= ngth is getting duplicated.

It's also true that we can reduce = the extra expense for WebSocket.=A0

= What we have is an additional expense for tunne= ling a connection. If the underlying protocol is transparent there is nothi= ng that can be done to prevent this.=A0

=A0<= /p>

Otherwise we will have= to write a mux extension for each transport that has to be multiplexed.

For example, we can define "raw-= " prefix for values used in the protocol field in the AddChannelReques= t block which I'm suggested. For raw-xxx protocol, multiplexing extensi= on provides simple tunneling. This way, we don't have to define multipl= exing extensions for each protocol.

--f46d0420a69507d42d04cbc05990-- From v-pramah@microsoft.com Wed Oct 10 21:58:34 2012 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 7035821F84E2 for ; Wed, 10 Oct 2012 21:58:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEf5rAPpjP+f for ; Wed, 10 Oct 2012 21:58:34 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0132721F84D6 for ; Wed, 10 Oct 2012 21:58:33 -0700 (PDT) Received: from BY2FFO11FD013.protection.gbl (10.1.15.201) by BY2FFO11HUB011.protection.gbl (10.1.14.82) with Microsoft SMTP Server (TLS) id 15.0.516.0; Thu, 11 Oct 2012 04:59:34 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Thu, 11 Oct 2012 04:59:33 +0000 Received: from SINEX14HUBC402.southpacific.corp.microsoft.com (157.60.220.216) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 11 Oct 2012 04:58:30 +0000 Received: from SINEX14MBXC405.southpacific.corp.microsoft.com ([169.254.5.92]) by SINEX14HUBC402.southpacific.corp.microsoft.com ([157.60.220.216]) with mapi id 14.02.0309.003; Thu, 11 Oct 2012 04:58:05 +0000 From: "Prashant Mahajan (Icertis Inc)" To: "hybi@ietf.org" Thread-Topic: WebSocket Protocol Thread-Index: Ac2nbP0Xrhm+E+EbTlGxraR8WBu+rQ== Date: Thu, 11 Oct 2012 04:58:05 +0000 Message-ID: <71636B367FF5B74F8C75E6998C03546A34E0678E@SINEX14MBXC405.southpacific.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.84] Content-Type: multipart/alternative; boundary="_000_71636B367FF5B74F8C75E6998C03546A34E0678ESINEX14MBXC405s_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(1076001)(5343635001)(15202345001)(47736001)(512954001)(74662001)(44976002)(33656001)(42186003)(49866001)(50986001)(16696001)(5343655001)(51856001)(46102001)(16406001)(4196001)(4396001)(47976001)(16826001)(31966008)(3846001)(47446002)(74502001)(20776001)(8716001)(306001)(316001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0631F0BC3D X-Mailman-Approved-At: Wed, 10 Oct 2012 23:16:08 -0700 Subject: [hybi] WebSocket Protocol 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, 11 Oct 2012 05:17:00 -0000 --_000_71636B367FF5B74F8C75E6998C03546A34E0678ESINEX14MBXC405s_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I am a newcomer developer for HTML5. From the articles what I got is, the r= eal use of Web Socket protocol is in IM application. Am I right? I like this new feature. Thanks, _______________________________________________________________ Prashant Mahajan | ICERTIS | p. +91 90964 56206 | e. v-pramah@microsoft.com= --_000_71636B367FF5B74F8C75E6998C03546A34E0678ESINEX14MBXC405s_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I am a newcomer developer for HTML5. From the articl= es what I got is, the real use of Web Socket protocol is in IM application.= Am I right?

 

I like this new feature.

 

Thanks,=

_______= ________________________________________________________<= /p>

Prashan= t Mahajan | ICERTIS | p. +91 90964 56206 | e. v-pram= ah@microsoft.com

 

--_000_71636B367FF5B74F8C75E6998C03546A34E0678ESINEX14MBXC405s_-- From SRS0+0ddfe9d8745db3e9=II=noemax.com=arman@noemax.com Thu Oct 11 01:43:00 2012 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 F2DEF21F86F0 for ; Thu, 11 Oct 2012 01:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWhf-Lem2yvc for ; Thu, 11 Oct 2012 01:42:59 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7AF21F86DD for ; Thu, 11 Oct 2012 01:42:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1349944980; x=1350549780; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=1HyZl1DPuOgxBb/0yDFyFBwOMrw=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=H9c30pkdErLSBBgAoh59cLxBh6NkXHzfJ+hsMPSQJKeZC3ab9whKQFmWVahUGNa5FocnVAW1+y4TdmlUU8a9KuUtSjd2JBi4El6y/fyJ2lTxSlfpb/XXxaYcpKld1Jf9imYy4kE5EOFb5Iji2SIh8vp/hyud5F6h7ynnQyPBltc= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.3) with ASMTP (SSL) id VSB17959; Thu, 11 Oct 2012 11:42:59 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <20121010092909.3656.83823.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4339129C5B6@EXVMBX020-12.exch020.serverdata.net> <000601cda6de$1d520f00$57f62d00$@noemax.com> <001501cda6f0$32e14b80$98a3e280$@noemax.com> In-Reply-To: Date: Thu, 11 Oct 2012 11:42:52 +0300 Message-ID: <006301cda78c$6a0adfd0$3e209f70$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01CDA7A5.8F5E3250" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKu7vlx8cDeHauGs2fWB5Gg+Gc1aQKub5i9AgxQ/VcBk4fQ7wHXY9caAkUy9AMByXXxoJWPlyGA Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.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, 11 Oct 2012 10:27:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01CDA7A5.8F5E3250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Thursday, October 11, 2012 6:41 AM To: Arman Djusupov Cc: Tobias Oberstein; hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.txt On Wed, Oct 10, 2012 at 11:04 PM, Arman Djusupov wrote: So your idea is to allocate N WS logical channels where N is concurrency and reuse established but unused WS sessions for next SPDY stream? Yes, once the SPDY stream is closed its stream ID is de-allocated and not used anymore. I simply suggest to open as many logical channels as SPDY requests concurrently, but when SPDY releases the stream I suggest to not drop the logical channel but instead to keep it open in order to reuse it for subsequent SPDY stream allocations. So initially WS-mux would allocate as many logical channels as SPDY requested and later it would be allocating a new logical channel only when there are no idle logical channels available when a new SPDY stream is requested. Since the WS-mux spec allows us to send the payload after sending an AddChannelRequest, SPDY should not have any additional latency imposed by WS-mux. Concerning header compression, since the browser SPDY implementation is aware that SPDY is muxed over WS, it should be able to compress the headers of all SPDY streams allocated over the same physical connection using a common DEFLATE state and make sure that they are processed in the order they were compressed. If SPDY can also be mapped to WS-mux frame one to one, then we can remove the 31 bit Stream ID and 24 bit length header used by SPDY. But my initial idea was to simply tunnel SPDY so that it benefits from WS handshake and does not require TLS/NPN. For example, we can define "raw-" prefix for values used in the protocol field in the AddChannelRequest block which I'm suggested. For raw-xxx protocol, multiplexing extension provides simple tunneling. This way, we don't have to define multiplexing extensions for each protocol. Something like that is also possible. With best regards, Arman ------=_NextPart_000_0064_01CDA7A5.8F5E3250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Thursday, = October 11, 2012 6:41 AM
To: Arman Djusupov
Cc: = Tobias Oberstein; hybi@ietf.org
Subject: Re: [hybi] I-D = Action: = draft-ietf-hybi-websocket-multiplexing-08.txt

 

On Wed, = Oct 10, 2012 at 11:04 PM, Arman Djusupov <arman@noemax.com> = wrote:

So your idea is to allocate N WS logical = channels where N is concurrency and reuse established but unused WS = sessions for next SPDY stream?

 

Yes, once the SPDY stream is closed its stream ID is de-allocated and = not used anymore. I simply suggest to open as many logical channels as = SPDY requests concurrently, but when SPDY releases the stream I suggest = to not drop the logical channel but instead to keep it open in order to = reuse it for subsequent SPDY stream allocations. So initially WS-mux = would allocate as many logical channels as SPDY requested and later it = would be allocating a new logical channel only when there are no idle = logical channels available when a new SPDY stream is requested. Since = the WS-mux spec allows us to send the payload after sending an = AddChannelRequest, SPDY should not have any additional latency imposed = by WS-mux.

 

Concerning header compression, since the browser SPDY implementation = is aware that SPDY is muxed over WS, it should be able to compress the = headers of all SPDY streams allocated over the same physical connection = using a common DEFLATE state and make sure that they are processed in = the order they were compressed.

 

If SPDY can also be mapped to WS-mux frame one to one, then we can = remove the 31 bit Stream ID and 24 bit length header used by = SPDY.

 

But my initial idea was to simply tunnel SPDY so that it benefits = from WS handshake and does not require TLS/NPN.

 

For example, = we can define "raw-" prefix for values used in the protocol = field in the AddChannelRequest block which I'm suggested. For raw-xxx = protocol, multiplexing extension provides simple tunneling. This way, we = don't have to define multiplexing extensions for each = protocol.

 

Something like that is also possible.=

 

With best regards,

Arman

 

------=_NextPart_000_0064_01CDA7A5.8F5E3250-- From tyoshino@google.com Thu Oct 11 08:11:51 2012 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 4DBC821F8714 for ; Thu, 11 Oct 2012 08:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.788 X-Spam-Level: X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+CirbkM-0pJ for ; Thu, 11 Oct 2012 08:11:50 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2AC21F86F8 for ; Thu, 11 Oct 2012 08:11:50 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3701022iec.31 for ; Thu, 11 Oct 2012 08:11: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:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=/MGYOm/iA9FIzn+60zo//aa/7IrKwc18iw9JaRz9Y3A=; b=doCbbRvcGpSHSTWTlIr/VRnRqh5AJkQ83Hpa2mw0dvym3hM9mk145SazP/grX6vbyx 0F4hAObgZYxjWl0wUBe/sS9KFmhSemrZnvz7pUA9u7fCt6BNzTE4fLjfhgiWbzYAEXBZ IGiXY6tX28ey0Uf2dqb5WtZeKrg9kic0m0GH3anFYbJWxxIRO07GGUJdWGuZSP0r/B6w CkMgx3UvhMhr712nQeAhf48tHKWZTpsnHclTomDJ0Rh9SBjrTags5dJA+VYuGr5FtWZx /73QaytxCj4VTEZLFZWhh4DlwoEus+I5ncHGvCT//0bmq7UirqJ0cJf9jp8tR9n6YVMH JAuw== 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-system-of-record:x-gm-message-state; bh=/MGYOm/iA9FIzn+60zo//aa/7IrKwc18iw9JaRz9Y3A=; b=I3XTDP2DcLV8S/GDuWQFPvM4dIzVbY5qBOxaZKNjzQHJKdQDpZHHp4akF+QTlV9Fxk v+T8N7PsV2GHum1D4mTpjOlJgLFNvG+YERvAAofuimb5nfkyy8z53XLP9vjN5wCycY/z NaMRK86jZ1HBJJFLe/K4QbJNm1djhsm7s4r4rn+cFsThKCvFEWd0iCmxfYVh/+ZvHaHt NhE7NtzSxBun/vbVB5HBEhMzPNVtO/jM8vcoihF+T/GOSrugmmcL9DRPjHRTpnkJ8X1f zoPvDegSewMsyOfwrbONHevoJfJlO/B6WRjo7eT1+dyiWCsCKHnsGAuH9mpQqjHj4fkC walA== Received: by 10.43.46.135 with SMTP id uo7mr933390icb.45.1349968310236; Thu, 11 Oct 2012 08:11:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Thu, 11 Oct 2012 08:11:29 -0700 (PDT) In-Reply-To: <006301cda78c$6a0adfd0$3e209f70$@noemax.com> References: <20121010092909.3656.83823.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4339129C5B6@EXVMBX020-12.exch020.serverdata.net> <000601cda6de$1d520f00$57f62d00$@noemax.com> <001501cda6f0$32e14b80$98a3e280$@noemax.com> <006301cda78c$6a0adfd0$3e209f70$@noemax.com> From: Takeshi Yoshino Date: Fri, 12 Oct 2012 00:11:29 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=bcaec5299a4396f73504cbc9fd49 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkQfJ9iDx/Wlm/yGKXHUoUzZ4yQfXqXzvbHIAJGXD6EJqYnzSwxdG7wf1ayiQfM9v+3IF9PV71MRyao+9hkuPVZX/yXzV8zd/1DOYbkoGppaS93IqFYlrGMAi7UaFgSJb+/jcxIKivQNtw4NAYyPHS8LeeB1r51EEkkZzJkGdPmuShl2RZocE7d5CcLVyb7xA02aubU Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-08.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, 11 Oct 2012 15:11:51 -0000 --bcaec5299a4396f73504cbc9fd49 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 11, 2012 at 5:42 PM, Arman Djusupov wrote: > On Wed, Oct 10, 2012 at 11:04 PM, Arman Djusupov wrote: > > ** > > Concerning header compression, since the browser SPDY implementation is > aware that SPDY is muxed over WS, it should be able to compress the headers > of all SPDY streams allocated over the same physical connection using a > common DEFLATE state and make sure that they are processed in the order > they were compressed. > > Yes. SPDY needs to coordinate with multiplexing to know/control in which order AddChannelRequests are issued (received). WebSocket multiplexing has to guarantee this semantics. So, we cannot have WebSocket intermediary that understands only multiplexing. For example, we may not drop an AddChannelRequest without looking into tunneled SPDY header. So, it's not SPDY layered over WebSocket multiplexing, but something new built using WebSocket multiplexing and SPDY. It's ok but I think essentially it's not so different from current design (mapping SYN_STREAM to AddChannelRequest). > ** > > If SPDY can also be mapped to WS-mux frame one to one, then we can remove > the 31 bit Stream ID and 24 bit length header used by SPDY. > > Yes. We can map them. > **** > > ** ** > > But my initial idea was to simply tunnel SPDY so that it benefits from WS > handshake and does not require TLS/NPN. **** > > ** > > I think if httpbis decide to make non-TLS SPDY support mandatory, they'll define Upgrade based bootstrapping similar to WebSocket's one. HyBi spent long time to mature Upgrade mechanism for WebSocket, but it's independent from WebSocket framing and now available for any other protocols that want to share 80 port with HTTP. --bcaec5299a4396f73504cbc9fd49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 11, 2012 at 5:42 PM, Arman Djusupov = <arman@noemax.com> wrote:

O= n Wed, Oct 10, 2012 at 11:04 PM, Arman Djusupov <arman@noemax.com> wrote:

Concerning header compression, since the bro= wser SPDY implementation is aware that SPDY is muxed over WS, it should be = able to compress the headers of all SPDY streams allocated over the same ph= ysical connection using a common DEFLATE state and make sure that they are = processed in the order they were compressed.


Yes. = SPDY needs to coordinate with multiplexing to know/control in which order A= ddChannelRequests are issued (received). WebSocket multiplexing has to guar= antee this semantics.

So, we cannot have WebSocket intermediary that understa= nds only multiplexing. For example,=A0we may not drop an AddChannelRequest = without looking into tunneled SPDY header.

So, it&= #39;s not=A0SPDY layered over=A0WebSocket multiplexing, but something new b= uilt using WebSocket multiplexing and SPDY.

It's ok but I think essentially it's not so dif= ferent from current design (mapping SYN_STREAM to AddChannelRequest).
=
=A0
=

If SPDY can also be mapped to WS-mux frame one to one, = then we can remove the 31 bit Stream ID and 24 bit length header used by SP= DY.

=A0
Yes. We can = map them.
=A0

<= u>

=A0<= /p>

But my initial idea wa= s to simply tunnel SPDY so that it benefits from WS handshake and does not = require TLS/NPN.

=A0


I think if httpbis decide to make non-= TLS SPDY support mandatory, they'll define Upgrade based bootstrapping = similar to WebSocket's one. HyBi spent long time to mature Upgrade mech= anism for WebSocket, but it's independent from WebSocket framing and no= w available for any other protocols that want to share 80 port with HTTP.
=A0
--bcaec5299a4396f73504cbc9fd49-- From Gabriel.Montenegro@microsoft.com Fri Oct 12 09:50:09 2012 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 51FCA21F8703 for ; Fri, 12 Oct 2012 09:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxbq+IQwN3pL for ; Fri, 12 Oct 2012 09:50:08 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id B529921F86F5 for ; Fri, 12 Oct 2012 09:50:08 -0700 (PDT) Received: from BL2FFO11FD007.protection.gbl (10.173.161.200) by BL2FFO11HUB026.protection.gbl (10.173.161.50) with Microsoft SMTP Server (TLS) id 15.0.516.0; Fri, 12 Oct 2012 16:51:08 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Fri, 12 Oct 2012 16:51:08 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 12 Oct 2012 16:49:27 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.147]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0318.003; Fri, 12 Oct 2012 09:49:27 -0700 From: Gabriel Montenegro To: "hybi@ietf.org" Thread-Topic: Canceling the HyBi meeting in Atlanta Thread-Index: Ac2omXPfTogPUhZiRxay4IisHLG/Sg== Date: Fri, 12 Oct 2012 16:49:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C116373A78ETK5EX14MBXW604w_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51444002)(164054002)(3846001)(49866001)(16406001)(44976002)(512954001)(51856001)(74662001)(15202345001)(47976001)(47736001)(5343655001)(31966008)(4396001)(8716001)(46102001)(33656001)(47446002)(20776001)(16826001)(16696001)(74502001)(42186003)(4196001)(5343635001)(1076001)(50986001)(316001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0632519F33 Subject: [hybi] Canceling the HyBi meeting in Atlanta 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, 12 Oct 2012 16:50:09 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C116373A78ETK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Salvatore and I think that there is not enough momentum or reason to meet i= n Atlanta, so we're thinking of canceling the meeting for IETF 85. We might= meet again in Orlando at the subsequent IETF. Thanks, Gabriel --_000_CA566BAEAD6B3F4E8B5C5C4F61710C116373A78ETK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Salvatore and I think that there is not enough momen= tum or reason to meet in Atlanta, so we’re thinking of canceling the = meeting for IETF 85. We might meet again in Orlando at the subsequent IETF.=

 

Thanks,

 

Gabriel

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C116373A78ETK5EX14MBXW604w_-- From joakim@intalio.com Fri Oct 12 10:50:06 2012 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 7FCD821F875A for ; Fri, 12 Oct 2012 10:50:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMYviN2-zzeE for ; Fri, 12 Oct 2012 10:50:05 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 785EA21F8757 for ; Fri, 12 Oct 2012 10:50:05 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2837990qcg.31 for ; Fri, 12 Oct 2012 10:50:05 -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=V1AspWqPdmtNyszsZepCXkBRFUh27FZOcyUq4BdxcZY=; b=POt/23RZCGq40TLlQgmvzVYsIXLIfvlIJO5vNMMIEfOMtYHUABMs1efscpL/+BEJJs iGw1Zr95yB/jcDktbfHiVKmK9PD4+he9uhtFuCw/qQQya9PJqHBCV6rRNfwFa3j1igzk DDIN2JkRMNCak8yh3cHEk0GYcVxByf8T3GW3mpuYSNrxmXrPyzeOqz+ri3E9w2YC1mr6 Ui0DX0tnsFjYvdjUBliFmFY57RlpRTeKtmGTdLH8O1oRpFLbtlMZeidvRNL0wsNyDCX3 oqtgNJPoxUdMNa6NRhwWOunt/4aEQG90JHjRXoXf1vjl+drQf0Ni7fnF82t/dgmSGFNC Q45Q== MIME-Version: 1.0 Received: by 10.224.199.10 with SMTP id eq10mr8631719qab.5.1350064204937; Fri, 12 Oct 2012 10:50:04 -0700 (PDT) Received: by 10.49.52.101 with HTTP; Fri, 12 Oct 2012 10:50:04 -0700 (PDT) In-Reply-To: References: <20121001112513.3691.55739.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 10:50:04 -0700 Message-ID: From: Joakim Erdfelt To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=20cf300fb32f5bfb3804cbe051a6 X-Gm-Message-State: ALoCoQkIQDsF7mP2C+z895NKs3oW5nauQdjTF6NNFdJA3QoODj8r73L5T765o7SWWtPcX2RNQ5I1 Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-01.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: Fri, 12 Oct 2012 17:50:06 -0000 --20cf300fb32f5bfb3804cbe051a6 Content-Type: text/plain; charset=ISO-8859-1 About the Examples section ... Can there be some wording about the current set of examples that they represent just a single frame's payload data? (or something similar) Also since we are now dealing with permessage, would it be useful to see Examples showing compression across multiple frames? And with that in mind, is there any relationship between frames and blocks of compressed data? For example, what would the spec say with regards to a single block of deflate compressed data arriving via 2+ frames? (hope that's allowed) -- Joakim Erdfelt www.webtide.com Developer advice, services and support from the Jetty & CometD experts. On Mon, Oct 1, 2012 at 4:54 AM, Takeshi Yoshino wrote: > No semantic change. > > - Clarified how the next block should be appended to a block with BFINAL=1 > - Added texts to examples to explain what data each of the bytes contains > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --20cf300fb32f5bfb3804cbe051a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
About the Examples section ...

Can there be s= ome wording about the current set of examples that they represent just a si= ngle frame's payload data? (or something similar)

Also since we are now dealing with permessage, would it be useful to s= ee Examples showing compression across multiple frames?

And with that in mind, is there any relationship between frames and b= locks of compressed data?
For example, what would the spec say with regards to a single block of= deflate compressed data arriving via 2+ frames? (hope that's allowed)<= /div>

--
Joakim Erdfelt <joakim@intalio.com>



On Mon, Oct 1, 2012 at 4:54 AM, Takeshi = Yoshino <tyoshino@google.com> wrote:
No semantic change.

- Clarified how the next block shoul= d be appended to a block with BFINAL=3D1
- Added texts to example= s to explain what data each of the bytes contains


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


--20cf300fb32f5bfb3804cbe051a6-- From tyoshino@google.com Fri Oct 12 11:28:28 2012 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 2E12221F86C3 for ; Fri, 12 Oct 2012 11:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kxE2RLzbqA2 for ; Fri, 12 Oct 2012 11:28:27 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3A121F86A2 for ; Fri, 12 Oct 2012 11:28:27 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so2611005iad.31 for ; Fri, 12 Oct 2012 11:28:26 -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:x-system-of-record; bh=EW3dQ9q8qZaU8GjJM9sIghxGsCV0rKEwcqbLpfN9y5w=; b=ODtt7yBggHd5WJ13C8SSImlfcE3TmSU9FRPZ+EMdWP225Vs+7uxhVxmOZkJ60lGLkZ JdWOw/xvhc4GDBFfXWnsZvEMPtgpng2cAu0e6gUopNmMLMturAumUITEgNtx2pfNQVl0 vIOQ7ljPSaLhfILsOS51tY7FbCBnO7d0sm3i0878jdiQ4vN/pBiaW6E0sOBkrzdtN+8p VqpUey9HhaP3SWAFMVtykVzq/SOpZQMX8M4seC3eLrgHEOPitWZOCFiLizrXGs4Fdo1L W5DrKieLRP5AvleN8901yXmOmjPmXlnQDorsk5eSswgeehdPKxak1xL3xwyjsTfDwClf 21GQ== 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-system-of-record:x-gm-message-state; bh=EW3dQ9q8qZaU8GjJM9sIghxGsCV0rKEwcqbLpfN9y5w=; b=aHx35llAA1YNTDuVdro3VvZO8jkbP6GhFN3lTttm3lpotIOjvgX7ETnc3QGw1Zvh5g MoPqFX2ebbkYJLSPM+yENqfEajL4ppg3BBzWY4xw0uH1fib+1PgwAXnEDskQ4feAyve4 k1MrlaT3XbI4flbQvhdc7XmwYTqbPQh/MUHFSIGZvE+c3GXLbnUDE4Ix628L9IsCRtrc LCgSL19SrW8OpDzcfLzumthTq6cxaYyZ9HWlmxYnoHZiVS3vt0yGnvY4/3LCzUuKBWgT ymIpWhwW1ZheTRB37Nsa/VQ4NqdZrcGCkJWJnnV+ZwPmLDYuyNC59Gp5+rxLmUCI0t6Z tBaQ== Received: by 10.50.194.132 with SMTP id hw4mr3007505igc.35.1350066506664; Fri, 12 Oct 2012 11:28:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Fri, 12 Oct 2012 11:28:06 -0700 (PDT) In-Reply-To: References: <20121001112513.3691.55739.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Sat, 13 Oct 2012 03:28:06 +0900 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=14dae93411e98d8b3404cbe0dab0 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnvg43D/go571qORup8tVpjDoeEUpjaNPhIuTo6QKb5U55+yqzeHlPbDDrqlKkQtLyQXC6tGwEmB0w2tS9srFVEXGS8CMeDGH5M1hQcYsxXsIzfq8qrleDCXLCYMYfs6J94N1jbCp0OhWFGcV75AdEjugkKo605UZxK0KiTYFWG7bKVlim+fPZfHMZTJ50BYETkOk+L Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-01.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: Fri, 12 Oct 2012 18:28:28 -0000 --14dae93411e98d8b3404cbe0dab0 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 13, 2012 at 2:50 AM, Joakim Erdfelt wrote: > About the Examples section ... > > Can there be some wording about the current set of examples that they > represent just a single frame's payload data? (or something similar) > Yes. Only octets to be set in payload data portion is printed. Each of them (each line starting with * symbol) represents one of a single frame. > > Also since we are now dealing with permessage, would it be useful to see > Examples showing compression across multiple frames? > > OK. I'll add some examples with fragmentation. > And with that in mind, is there any relationship between frames and blocks > of compressed data? > For example, what would the spec say with regards to a single block of > deflate compressed data arriving via 2+ frames? (hope that's allowed) > Right. Now fragmentation is transparent to compression. Compressed message payload can be cut at any positions into 2 or more frames. It's fine to cut in the middle of a deflate block. > > -- > Joakim Erdfelt > www.webtide.com > Developer advice, services and support > from the Jetty & CometD experts. > > > > On Mon, Oct 1, 2012 at 4:54 AM, Takeshi Yoshino wrote: > >> No semantic change. >> >> - Clarified how the next block should be appended to a block with BFINAL=1 >> - Added texts to examples to explain what data each of the bytes contains >> >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> > --14dae93411e98d8b3404cbe0dab0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 13, 2012 at 2:50 AM, Joakim Erdfelt <joakim@intalio.com&g= t; wrote:
About the Examples section ...

Can there be s= ome wording about the current set of examples that they represent just a si= ngle frame's payload data? (or something similar)

Yes. Only octets to be set in payload data portion is p= rinted. Each of them (each line starting with * symbol) represents one of a= single frame.
=A0

Also since we are now dealing with permessage, would it be useful to s= ee Examples showing compression across multiple frames?


OK. I'll add some examples with fragm= entation.
=A0
And with that = in mind, is there any relationship between frames and blocks of compressed = data?
For example, what would the spec say with regards to a single block of= deflate compressed data arriving via 2+ frames? (hope that's allowed)<= /div>

Right. Now fragmentation is transpare= nt to=A0compression.=A0Compressed message payload can be cut at any positio= ns into 2 or more frames. It's fine to cut in the middle of a deflate b= lock.
=A0

--
Joakim Erdfelt <joakim@intalio.com>



No semantic change.

- Clarified how the next block shoul= d be appended to a block with BFINAL=3D1
- Added texts to example= s to explain what data each of the bytes contains


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



--14dae93411e98d8b3404cbe0dab0-- From joakim@intalio.com Fri Oct 12 12:40:01 2012 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 7BFC021F86F7 for ; Fri, 12 Oct 2012 12:40:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PniNd4GBVCgv for ; Fri, 12 Oct 2012 12:40:00 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D18721F86C3 for ; Fri, 12 Oct 2012 12:40:00 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3122865pad.31 for ; Fri, 12 Oct 2012 12:40:00 -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=nDWns37VTK36Pqm2/bbbbupiUmErjNnOsU42UFIG6O4=; b=UC1n4WEA+/e2xz4/WwjdtmAKUQqkT6bvGMSUSmxUrgQBmhK0M1Ckzuexax5dCuADFJ mbufg43rd3D2bVgLffmw39fEKfi5/hS7KmRkOuF5THrqPHtbxc0vQzQs8dp84czQCCEh ODIZsM9mE1i315lx1T8I+aHEf3wq+3OxQuC3SemEDxYNtZp8fGTp9rvaCYKgF38xWOK9 +jnEit7/+6wxtJgRgupsk1RXmNe2pwWOXg1lOrEZEwxugqwEA8z4StEMuyoKwMJbKG5z PoiHJuHwzfOdZLfI0eK1mD8bKDjafrI4V1EudrbScU8z2fJZv9QOAdlW44Fm6ecXz9Hu f+dA== MIME-Version: 1.0 Received: by 10.66.75.162 with SMTP id d2mr13750099paw.27.1350070799979; Fri, 12 Oct 2012 12:39:59 -0700 (PDT) Received: by 10.66.254.99 with HTTP; Fri, 12 Oct 2012 12:39:59 -0700 (PDT) In-Reply-To: References: <20121001112513.3691.55739.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 12:39:59 -0700 Message-ID: From: Joakim Erdfelt To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=f46d042dfd7174549704cbe1da4a X-Gm-Message-State: ALoCoQnOFWS0KegE9KRSvMD3no8F87ANAuQ2wO6DHUKsrt1eShRTAWPJDjPkDJXzpqxR2fh02FNU Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-01.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: Fri, 12 Oct 2012 19:40:01 -0000 --f46d042dfd7174549704cbe1da4a Content-Type: text/plain; charset=ISO-8859-1 (I'm working on the support for this extension in the Eclipse Jetty Web Server codebase) Just a sanity check ... Are the existing Examples sane / valid? Using the built-in Deflate algorithms in Java, in the first example that specifies the use of the LZ77 sliding window, java reports the second block as "invalid stored block lengths". ( this behavior is indicative that we are getting a Z_DATA_ERROR somewhere in the native code. Our initial investigation shows line #159 here as a code path we are in ... http://cr.openjdk.java.net/~sherman/7188852/webrev/src/share/native/java/util/zip/Inflater.c-.html ) Also, I've been having much heartburn over some of the Deflate specifics laid out in spec wrt java's native Deflate implementation. Namely: * Java always produces a BFINAL 1 block (looking at the openjdk source, I can see no way for BFINAL 0 to ever be produced). Already filed a bug with chromium folks about this (as chromium fails to decompress if server generates a block using BFINAL 1) ... https://code.google.com/p/chromium/issues/detail?id=155060 * The various method parameters .. "s2c_max_window_bits", "c2s_max_window_bits", "s2c_no_context_takeover", "c2s_no_context_takeover" are all seemingly impossible to control with the native Java Deflate implementations. Also, I'd like to discuss the last 2 paragraphs on section 5.1 indicating that the client "MUST fail" the websocket connection if these method configuration parameters are not supported. Can we get this relaxed to "MAY fail" instead? Allowing the endpoints to negotiate capabilities instead of failing? As the spec stands now, in order for someone on java to support the compression, they'll have to use a 100% java (non-native) Deflate/ZLib implementation to support these parts of the spec. For performance reasons, this is troublesome to me, as the native implementations use zlib currently, are blazingly fast, work on multiple devices (even mobile phones), and are mature and well debugged. The native Deflate/Zlib support in java works fine for HTTP w/deflate (and even gzip) Content-Encoding, its a shame that we'll have to either implement Deflate ourselves, or pull in a 3rd party Deflate algorithm (as we have to be careful about Eclipse IP due diligence and cleanliness requirements). Thanks for listening. -- Joakim Erdfelt www.webtide.com Developer advice, services and support from the Jetty & CometD experts. On Fri, Oct 12, 2012 at 11:28 AM, Takeshi Yoshino wrote: > On Sat, Oct 13, 2012 at 2:50 AM, Joakim Erdfelt wrote: > >> About the Examples section ... >> >> Can there be some wording about the current set of examples that they >> represent just a single frame's payload data? (or something similar) >> > > Yes. Only octets to be set in payload data portion is printed. Each of > them (each line starting with * symbol) represents one of a single frame. > > >> >> Also since we are now dealing with permessage, would it be useful to see >> Examples showing compression across multiple frames? >> >> > OK. I'll add some examples with fragmentation. > > >> And with that in mind, is there any relationship between frames and >> blocks of compressed data? >> For example, what would the spec say with regards to a single block of >> deflate compressed data arriving via 2+ frames? (hope that's allowed) >> > > Right. Now fragmentation is transparent to compression. Compressed message > payload can be cut at any positions into 2 or more frames. It's fine to cut > in the middle of a deflate block. > > >> >> -- >> Joakim Erdfelt >> www.webtide.com >> Developer advice, services and support >> from the Jetty & CometD experts. >> >> >> >> On Mon, Oct 1, 2012 at 4:54 AM, Takeshi Yoshino wrote: >> >>> No semantic change. >>> >>> - Clarified how the next block should be appended to a block with >>> BFINAL=1 >>> - Added texts to examples to explain what data each of the bytes contains >>> >>> >>> _______________________________________________ >>> hybi mailing list >>> hybi@ietf.org >>> https://www.ietf.org/mailman/listinfo/hybi >>> >>> >> > --f46d042dfd7174549704cbe1da4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (I'm working on the support for this extension in the Eclipse Jetty Web= Server codebase)

Just a sanity check ...

=
Are the existing Examples sane / valid?

Using= the built-in Deflate algorithms in Java, in the first example that specifi= es the use of the LZ77 sliding window, java reports the second block as &qu= ot;invalid stored block lengths".=A0
( this behavior is=A0indicative=A0that we are getting a Z_DATA_ERROR s= omewhere in the native code. =A0Our initial investigation shows line #159 h= ere as a code path we are in ...=A0http= ://cr.openjdk.java.net/~sherman/7188852/webrev/src/share/native/java/util/z= ip/Inflater.c-.html=A0)

Also, I've been having much heartburn over some of = the Deflate specifics laid out in spec wrt java's native Deflate implem= entation.
Namely:

* Java always produces= a BFINAL 1 block (looking at the openjdk source, I can see no way for BFIN= AL 0 to ever be produced).
=A0 =A0Already filed a bug with chromium folks about this (as chromium= fails to decompress if server generates a block using BFINAL 1) ...
<= div>=A0 =A0 =A0https://code.google.com/p/chromium/issues/detail?id=3D155060
* The various method parameters .. "s2c_max_window_bits", &q= uot;c2s_max_window_bits", "s2c_no_context_takeover", "c= 2s_no_context_takeover" are all seemingly impossible to control with t= he native Java Deflate implementations.

Also, I'd like to discuss the last 2 paragraphs on = section 5.1 indicating that the client "MUST fail" the websocket = connection if these method configuration parameters are not supported. =A0C= an we get this relaxed to "MAY fail" instead? =A0Allowing the end= points to negotiate capabilities instead of failing?

As the spec stands now, in order for someone on java to= support the compression, they'll have to use a 100% java (non-native) = Deflate/ZLib implementation to support these parts of the spec. =A0 For per= formance reasons, this is troublesome to me, as the native implementations = use zlib currently, are blazingly fast, work on multiple devices (even mobi= le phones), and are mature and well debugged.

The native Deflate/Zlib support in java works fine for = HTTP w/deflate (and even gzip) Content-Encoding, its a shame that we'll= have to either implement Deflate ourselves, or pull in a 3rd party Deflate= algorithm (as we have to be careful about Eclipse IP due diligence and cle= anliness requirements).
Developer advice, services and support
from the = Jetty & CometD experts.



On Fri, Oct 12, 2012 at 11:28 AM, Takesh= i Yoshino <tyoshino@google.com> wrote:
On Sat, Oct 13, 2012 at 2:50 AM, Joakim Erdfelt <joakim= @intalio.com> wrote:
About the Examples section ...

Can there be s= ome wording about the current set of examples that they represent just a si= ngle frame's payload data? (or something similar)

Yes. Only octets to be set in payload data portio= n is printed. Each of them (each line starting with * symbol) represents on= e of a single frame.
=A0

Also since we are now dealing with permessage, would it be useful to s= ee Examples showing compression across multiple frames?


OK. I'll add some examples with= fragmentation.
=A0
And with that = in mind, is there any relationship between frames and blocks of compressed = data?
For example, what would the spec say with regards to a single block of= deflate compressed data arriving via 2+ frames? (hope that's allowed)<= /div>

Right. Now fragmentation is tra= nsparent to=A0compression.=A0Compressed message payload can be cut at any p= ositions into 2 or more frames. It's fine to cut in the middle of a def= late block.
=A0

--
Joakim Erdfelt <joakim@intalio.com>



No semantic change.

- Clarified how the next block shoul= d be appended to a block with BFINAL=3D1
- Added texts to example= s to explain what data each of the bytes contains


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




--f46d042dfd7174549704cbe1da4a-- From joakim@intalio.com Fri Oct 12 13:07:39 2012 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 E0E3021F86F9 for ; Fri, 12 Oct 2012 13:07:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arVCaj05VBWV for ; Fri, 12 Oct 2012 13:07:38 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5E0B21F86A0 for ; Fri, 12 Oct 2012 13:07:38 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3229521pbb.31 for ; Fri, 12 Oct 2012 13:07: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:x-gm-message-state; bh=0gbO5tRzRJ1okGMxyGIy5n42YCIKbMMlZJIz4ZRHeR4=; b=U+CQkk3IvSVS0XblTRTyEbjxBgS3BdNZXQv2ROmX7XkerkP6hOnNlBdLwQFlFcxKxC HIG+kI9DGROzcU3dLuMqIt+gSV6l1zfTCPaD/5T7g3ICowg7GCNOj21sOzT7CKnIh0mX Qq3qoYHWbST3KYUOKYW1+6I0q3wWwfUdfaE0/j3k5R1dq0bzsUf/pcLzvt9zGtN7YwZI 42srTRP2T5fDeF9mOQdH0DLv8NxPCAvw98tXkIFCp8TJeIstvaEAWL1J/o+ymRS0zjKC QRNJ+F2A82pEFPc9BusT0XEyA9uiCVnxxb9vpnC/2gCGh9KXr7euwpEbxln2TQNOLazU G2Mg== MIME-Version: 1.0 Received: by 10.68.134.97 with SMTP id pj1mr16479783pbb.55.1350072457962; Fri, 12 Oct 2012 13:07:37 -0700 (PDT) Received: by 10.66.254.99 with HTTP; Fri, 12 Oct 2012 13:07:37 -0700 (PDT) In-Reply-To: References: <20121001112513.3691.55739.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 13:07:37 -0700 Message-ID: From: Joakim Erdfelt To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=047d7b111a314725f904cbe23dec X-Gm-Message-State: ALoCoQmdotGlTyFRk5Z8XG2jurkzg88+8bfgYL5O12aPp2EHLkMT/T25hAGdz31pQQ3rPOYTQNGx Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-01.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: Fri, 12 Oct 2012 20:07:40 -0000 --047d7b111a314725f904cbe23dec Content-Type: text/plain; charset=ISO-8859-1 Update. The 2 blocks in Example 1 can be handled by Java's Deflate but the delimiters for the block of data have to be known ahead of time. If that example arrives as a single frame of data seen like ... 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0xf2 0x00 0x11 0x00 0x00 Then this is invalid to Java's Deflate implementation. However, if the first block is decoded, followed the octets [0x00 0x00 0xFF 0xFF] (empty block with no compression?) are provided to the inflate algorithm, then the second block is valid to Java's native implementation of Deflate, at which point the 2 "Hello" texts can be decoded correctly. So this leads me to believe that the spec should have some language that the start of a block can never appear in the middle of a single compressed message (regardless of number of frames) to support this. Or is there some language for an implied delimiter of blocks that isn't clear in the spec right now? -- Joakim Erdfelt www.webtide.com Developer advice, services and support from the Jetty & CometD experts. On Fri, Oct 12, 2012 at 12:39 PM, Joakim Erdfelt wrote: > (I'm working on the support for this extension in the Eclipse Jetty Web > Server codebase) > > Just a sanity check ... > > Are the existing Examples sane / valid? > > Using the built-in Deflate algorithms in Java, in the first example that > specifies the use of the LZ77 sliding window, java reports the second block > as "invalid stored block lengths". > ( this behavior is indicative that we are getting a Z_DATA_ERROR somewhere > in the native code. Our initial investigation shows line #159 here as a > code path we are in ... > http://cr.openjdk.java.net/~sherman/7188852/webrev/src/share/native/java/util/zip/Inflater.c-.html > ) > > Also, I've been having much heartburn over some of the Deflate specifics > laid out in spec wrt java's native Deflate implementation. > Namely: > > * Java always produces a BFINAL 1 block (looking at the openjdk source, I > can see no way for BFINAL 0 to ever be produced). > Already filed a bug with chromium folks about this (as chromium fails > to decompress if server generates a block using BFINAL 1) ... > https://code.google.com/p/chromium/issues/detail?id=155060 > * The various method parameters .. "s2c_max_window_bits", > "c2s_max_window_bits", "s2c_no_context_takeover", "c2s_no_context_takeover" > are all seemingly impossible to control with the native Java Deflate > implementations. > > Also, I'd like to discuss the last 2 paragraphs on section 5.1 indicating > that the client "MUST fail" the websocket connection if these method > configuration parameters are not supported. Can we get this relaxed to > "MAY fail" instead? Allowing the endpoints to negotiate capabilities > instead of failing? > > As the spec stands now, in order for someone on java to support the > compression, they'll have to use a 100% java (non-native) Deflate/ZLib > implementation to support these parts of the spec. For performance > reasons, this is troublesome to me, as the native implementations use zlib > currently, are blazingly fast, work on multiple devices (even mobile > phones), and are mature and well debugged. > > The native Deflate/Zlib support in java works fine for HTTP w/deflate (and > even gzip) Content-Encoding, its a shame that we'll have to either > implement Deflate ourselves, or pull in a 3rd party Deflate algorithm (as > we have to be careful about Eclipse IP due diligence and cleanliness > requirements). > > Thanks for listening. > > -- > Joakim Erdfelt > www.webtide.com > Developer advice, services and support > from the Jetty & CometD experts. > > > > On Fri, Oct 12, 2012 at 11:28 AM, Takeshi Yoshino wrote: > >> On Sat, Oct 13, 2012 at 2:50 AM, Joakim Erdfelt wrote: >> >>> About the Examples section ... >>> >>> Can there be some wording about the current set of examples that they >>> represent just a single frame's payload data? (or something similar) >>> >> >> Yes. Only octets to be set in payload data portion is printed. Each of >> them (each line starting with * symbol) represents one of a single frame. >> >> >>> >>> Also since we are now dealing with permessage, would it be useful to see >>> Examples showing compression across multiple frames? >>> >>> >> OK. I'll add some examples with fragmentation. >> >> >>> And with that in mind, is there any relationship between frames and >>> blocks of compressed data? >>> For example, what would the spec say with regards to a single block of >>> deflate compressed data arriving via 2+ frames? (hope that's allowed) >>> >> >> Right. Now fragmentation is transparent to compression. Compressed >> message payload can be cut at any positions into 2 or more frames. It's >> fine to cut in the middle of a deflate block. >> >> >>> >>> -- >>> Joakim Erdfelt >>> www.webtide.com >>> Developer advice, services and support >>> from the Jetty & CometD experts. >>> >>> >>> >>> On Mon, Oct 1, 2012 at 4:54 AM, Takeshi Yoshino wrote: >>> >>>> No semantic change. >>>> >>>> - Clarified how the next block should be appended to a block with >>>> BFINAL=1 >>>> - Added texts to examples to explain what data each of the bytes >>>> contains >>>> >>>> >>>> _______________________________________________ >>>> hybi mailing list >>>> hybi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hybi >>>> >>>> >>> >> > --047d7b111a314725f904cbe23dec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Update.

The 2 blocks in Example 1 can be handled by Java= 's Deflate but the delimiters for the block of data have to be known ah= ead of time.
If that example arrives as a single frame of data se= en like ...

=A0=A00xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00=A00xf2 0x00 0x= 11 0x00 0x00

Then this is invalid to Java's De= flate implementation.
However, if the first block is decoded, fol= lowed the octets [0x00 0x00 0xFF 0xFF] (empty block with no compression?) a= re provided to the inflate algorithm, then the second block is valid to Jav= a's native implementation of Deflate, at which point the 2 "Hello&= quot; texts can be decoded correctly.

So this leads me to believe that the spec should have s= ome language that the start of a block can never appear in the middle of a = single compressed message (regardless of number of frames) to support this.= =A0Or is there some language for an implied delimiter of blocks that isn&#= 39;t clear in the spec right now?
Developer advice, services and support
from the = Jetty & CometD experts.



On Fri, Oct 12, 2012 at 12:39 PM, Joakim= Erdfelt <joakim@intalio.com> wrote:
(I'm working on the support for this extension in the Eclipse Jetty Web= Server codebase)

Just a sanity check ...

=
Are the existing Examples sane / valid?

Using= the built-in Deflate algorithms in Java, in the first example that specifi= es the use of the LZ77 sliding window, java reports the second block as &qu= ot;invalid stored block lengths".=A0
( this behavior is=A0indicative=A0that we are getting a Z_DATA_ERROR s= omewhere in the native code. =A0Our initial investigation shows line #159 h= ere as a code path we are in ...=A0http://cr.openjdk.java.net/~sherman/7188852/webrev/src/share/= native/java/util/zip/Inflater.c-.html=A0)

Also, I've been having much heartburn over some of = the Deflate specifics laid out in spec wrt java's native Deflate implem= entation.
Namely:

* Java always produces= a BFINAL 1 block (looking at the openjdk source, I can see no way for BFIN= AL 0 to ever be produced).
=A0 =A0Already filed a bug with chromium folks about this (as chromium= fails to decompress if server generates a block using BFINAL 1) ...
<= div>=A0 =A0 =A0https://code.google.com/p/chromium/issues/de= tail?id=3D155060
* The various method parameters .. "s2c_max_window_bits", &q= uot;c2s_max_window_bits", "s2c_no_context_takeover", "c= 2s_no_context_takeover" are all seemingly impossible to control with t= he native Java Deflate implementations.

Also, I'd like to discuss the last 2 paragraphs on = section 5.1 indicating that the client "MUST fail" the websocket = connection if these method configuration parameters are not supported. =A0C= an we get this relaxed to "MAY fail" instead? =A0Allowing the end= points to negotiate capabilities instead of failing?

As the spec stands now, in order for someone on java to= support the compression, they'll have to use a 100% java (non-native) = Deflate/ZLib implementation to support these parts of the spec. =A0 For per= formance reasons, this is troublesome to me, as the native implementations = use zlib currently, are blazingly fast, work on multiple devices (even mobi= le phones), and are mature and well debugged.

The native Deflate/Zlib support in java works fine for = HTTP w/deflate (and even gzip) Content-Encoding, its a shame that we'll= have to either implement Deflate ourselves, or pull in a 3rd party Deflate= algorithm (as we have to be careful about Eclipse IP due diligence and cle= anliness requirements).

Thanks for listening.

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



On Fri, Oct= 12, 2012 at 11:28 AM, Takeshi Yoshino <tyoshino@google.com> wrote:
On Sat, Oct 13, 2012 at 2:50 AM, Joakim Erdfelt <= joakim@intalio.com<= /a>> wrote:
=A0
And with that = in mind, is there any relationship between frames and blocks of compressed = data?
For example, what would the spec say with regards to a single block of= deflate compressed data arriving via 2+ frames? (hope that's allowed)<= /div>

Right. Now fragmentation is tra= nsparent to=A0compression.=A0Compressed message payload can be cut at any p= ositions into 2 or more frames. It's fine to cut in the middle of a def= late block.


No semantic change.

- Clarified how the next block shoul= d be appended to a block with BFINAL=3D1
- Added texts to example= s to explain what data each of the bytes contains


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





--047d7b111a314725f904cbe23dec-- From Gabriel.Montenegro@microsoft.com Fri Oct 12 16:10:42 2012 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 EA38221F86AD for ; Fri, 12 Oct 2012 16:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK0ceHuZ4dET for ; Fri, 12 Oct 2012 16:10:42 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8622821F857E for ; Fri, 12 Oct 2012 16:10:41 -0700 (PDT) Received: from BY2FFO11FD010.protection.gbl (10.1.15.203) by BY2FFO11HUB034.protection.gbl (10.1.14.118) with Microsoft SMTP Server (TLS) id 15.0.516.0; Fri, 12 Oct 2012 23:11:34 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Fri, 12 Oct 2012 23:11:34 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 12 Oct 2012 23:10:29 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.147]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0318.003; Fri, 12 Oct 2012 16:10:29 -0700 From: Gabriel Montenegro To: Takeshi Yoshino , "hybi@ietf.org" Thread-Topic: [hybi] "Cache-Control: no-cache" may improve handshake success rate Thread-Index: AQHNn5ZCck9IwVImC0CHJGPTuHw/Jpe2XgAg Date: Fri, 12 Oct 2012 23:10:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11637416C2TK5EX14MBXW604w_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(15202345001)(42186003)(47446002)(51856001)(5343655001)(5343635001)(74502001)(16696001)(16826001)(8716001)(512954001)(20776001)(3846001)(2666001)(4396001)(1076001)(4196001)(44976002)(74662001)(50986001)(33656001)(47976001)(46102001)(16406001)(47736001)(31966008)(49866001)(316001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0632519F33 Subject: Re: [hybi] "Cache-Control: no-cache" may improve handshake success rate 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, 12 Oct 2012 23:10:43 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11637416C2TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Takeshi, this is potentially low hanging fruit to obtain some impro= vement. BTW, is there any number about how much improvement has been obser= ved or could be expected? Thanks, Gabriel From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Tak= eshi Yoshino Sent: Sunday, 30 September, 2012 22:33 To: hybi@ietf.org Subject: [hybi] "Cache-Control: no-cache" may improve handshake success rat= e It seems adding the Cache-Control header to the WebSocket handshake improve= s success rate for some environment. We've investigated one bug report [1] for Chrome, and found that there're s= ome caches deployed in Thailand which corrupt server's opening handshakes b= y replacing the value in the Connection header with close. This doesn't happen if Firefox is used. Some tests using reduced header set= indicated that it's because Firefox puts the Cache-Control and Pragma head= er like this: Pragma: no-cache Cache-Control: no-cache in its WebSocket client's handshakes while Chrome does not send such header= s. I guess that the proxy is caching server's opening handshake and sending th= e cached data but after overwriting the Connection header ignoring the mean= ing of "Connection: Upgrade". Basically, we want Upgrade non-compliant proxies to be replaced with new on= es rather than taking work around, but don't have much reluctance to use of= the headers. ---- [1] http://code.google.com/p/chromium/issues/detail?id=3D148908 . Thanks ba= ngkokmaco. --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11637416C2TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Takeshi, this is = potentially low hanging fruit to obtain some improvement.  BTW, is the= re any number about how much improvement has been observed or could be expected?

 <= /p>

Thanks,=

 <= /p>

Gabriel=

 

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino
Sent: Sunday, 30 September, 2012 22:33
To: hybi@ietf.org
Subject: [hybi] "Cache-Control: no-cache" may improve hand= shake success rate

 

It seems adding the Cache-Control header to the WebS= ocket handshake improves success rate for some environment.

 

We've investigated one bug report [1] for Chrome, an= d found that there're some caches deployed in Thailand which corrupt server= 's opening handshakes by replacing the value in the Connection header with = close.

 

This doesn't happen if Firefox is used. Some tests u= sing reduced header set indicated that it's because Firefox puts the Cache-= Control and Pragma header like this:

 

Pragma: no-cache

Cache-Control: no-cache

 

in its WebSocket client's handshakes while Chrome do= es not send such headers.

 

I guess that the proxy is caching server's opening h= andshake and sending the cached data but after overwriting the Connection h= eader ignoring the meaning of "Connection: Upgrade".

 

Basically, we want Upgrade non-compliant proxies to = be replaced with new ones rather than taking work around, but don't have mu= ch reluctance to use of the headers.

 

----

 

 

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11637416C2TK5EX14MBXW604w_-- From tyoshino@google.com Fri Oct 12 21:26:24 2012 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 2E14A21F86B5 for ; Fri, 12 Oct 2012 21:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.811 X-Spam-Level: X-Spam-Status: No, score=-102.811 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKMs1m5xs+DW for ; Fri, 12 Oct 2012 21:26:23 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9E9521F869C for ; Fri, 12 Oct 2012 21:26:22 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so6661153iec.31 for ; Fri, 12 Oct 2012 21:26: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:x-system-of-record; bh=ch13csfQ+u3cW9d/kmpjA8X+PEC9W8nrXxjZMW//32I=; b=mHhJ6OvpaDqeVOvQidDyW+OyqzweouWoa7NqAvIyZmQ2bneMmokAUKvst0APZpTygr 3dW3Db0pIDEqfiCCa3zL6K//ygAT/s0wLt9fvop2OebeEzyHzmq+BxU6lJen9oVR0wZd Bcs5z7SJ4RiMwPACRiSen1fj3JGhWUOme05py+h0LD9qghLssm+ZsY4ftLjHkKezAsdZ UWv0j8F0B3taAvPSsaj/cOQqTOhYSk+kb2CuAffIyQ6w5KRQHNzIWuwPyAmN6TdpjEwm cSqJeWGIZ2YBfbSN+xyJWVkL/Zz2LSwPS+pO1XHJnPmvF1zBXeBh90lxrtm0iPoqt0B3 ilOw== 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-system-of-record:x-gm-message-state; bh=ch13csfQ+u3cW9d/kmpjA8X+PEC9W8nrXxjZMW//32I=; b=MkshjhRKozU+vdtXMxY1riyC7sUd69y+xV8uHrAwjH1ftMr1tkVKdRYNsnMauRptkh DgblYaaaPlPN+mndyb9CE1Uj4ekaE/BqnKds10T3/7JKUtLbn4w44TvFYEVnLlUc2KOT RfFyuTOq2i187ut7gFWyBddM6BVW8ksOVxoGu4mrgdyxeCmRYG+k46hbxoa5IOv/WExL UqeIGblHaeX1nNUnp9AFN0vHwzF3q7sKnSesavOOjeLecTbfJrMk2FNz8RDxqd5Cz4xD QbC7fDRQet8vA9mf0eXAWsO7hUMu5A6GFYzLfio7P8tN6O6PTKm5qaT1rwyj4YF5useq Y9nw== Received: by 10.50.185.200 with SMTP id fe8mr3919094igc.35.1350102382153; Fri, 12 Oct 2012 21:26:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Fri, 12 Oct 2012 21:26:01 -0700 (PDT) In-Reply-To: References: <20121001112513.3691.55739.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Sat, 13 Oct 2012 13:26:01 +0900 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=14dae9340673e611c804cbe9343f X-System-Of-Record: true X-Gm-Message-State: ALoCoQlu3eXallNWb7ZNx0IjiVMFWH8rEdTVH1PHKtkjxFkUVitmS5ij1yyhuGPLYkZfwWLIwNu6ZJY3JQAsb8gbQ4QvNzO/+m1ZjPG3sb5UiriGOYRESIK7GF7JkOvN4RqO6FlHgabjb2LGT3hC2iKMd8XT2S5RsuMVZjzAn/bFGfFBE5eruoayeuEJXxBJZWy6fxcCpjLw Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-01.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, 13 Oct 2012 04:26:24 -0000 --14dae9340673e611c804cbe9343f Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 13, 2012 at 4:39 AM, Joakim Erdfelt wrote: > (I'm working on the support for this extension in the Eclipse Jetty Web > Server codebase) > > Just a sanity check ... > > Are the existing Examples sane / valid? > > Using the built-in Deflate algorithms in Java, in the first example that > specifies the use of the LZ77 sliding window, java reports the second block > as "invalid stored block lengths". > Have you added 0x00 0x00 0xff 0xff to examples before pouring them into Inflater? > ( this behavior is indicative that we are getting a Z_DATA_ERROR > somewhere in the native code. Our initial investigation shows line #159 > here as a code path we are in ... > http://cr.openjdk.java.net/~sherman/7188852/webrev/src/share/native/java/util/zip/Inflater.c-.html > ) > > Also, I've been having much heartburn over some of the Deflate specifics > laid out in spec wrt java's native Deflate implementation. > Namely: > > * Java always produces a BFINAL 1 block (looking at the openjdk source, I > can see no way for BFINAL 0 to ever be produced). > Already filed a bug with chromium folks about this (as chromium fails > to decompress if server generates a block using BFINAL 1) ... > https://code.google.com/p/chromium/issues/detail?id=155060 > (with Chromium hat) We'll fix it. That's the reason why I've added BFINAL=1 options. I skimmed HyBi log and saw that Greg was talking about that limitation of Java. > * The various method parameters .. "s2c_max_window_bits", > "c2s_max_window_bits", "s2c_no_context_takeover", "c2s_no_context_takeover" > are all seemingly impossible to control with the native Java Deflate > implementations. > Please just reset your Deflate instance for each message if you received s2c_no_context_takeover. About s2c_max_window_bits, yes, you're right. I forgot to investigate if this is available on JDK. > > Also, I'd like to discuss the last 2 paragraphs on section 5.1 indicating > that the client "MUST fail" the websocket connection if these method > configuration parameters are not supported. Can we get this relaxed to > "MAY fail" instead? Allowing the endpoints to negotiate capabilities > instead of failing? > > It causes problem I think. The server has already declared that it can accept only data compressed using that window size. Rather than changing the MUST to MAY, I think we should let the client to announce it's capability by including c2s_max_window_bits in it's method description. I.e. if there's not c2s_max_window_bits token in request, the server MUST NOT request c2s_max_window_bits. JDK based client may exclude c2s_max_window_bits. We also need to relax is the last sentence of the paragraph defining s2c_max_window_bits. If the "accepted request" has this method parameter, the server MUST attach this method parameter with the same value as one of the "accepted request". Changing this "MUST" to "SHOULD" allows servers to reject window size reduction request. Thanks --14dae9340673e611c804cbe9343f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 13, 2012 at 4:39 AM, Joakim Erdfelt <joakim@intalio.com&g= t; wrote:
(I'm working on the support for this extension in the Eclipse Jetty Web= Server codebase)

Just a sanity check ...

=
Are the existing Examples sane / valid?

Using the built-in Deflate algorithms in Java, in the first example that sp= ecifies the use of the LZ77 sliding window, java reports the second block a= s "invalid stored block lengths".=A0

Have you added 0x00 0x00 0xff 0xff t= o examples before pouring them into Inflater?
=A0
( this behavior is=A0indicative=A0that we are getting a Z_DATA_ERROR s= omewhere in the native code. =A0Our initial investigation shows line #159 h= ere as a code path we are in ...=A0http://cr.openjdk.java.net/~sherman/7188852/webrev/src/share/= native/java/util/zip/Inflater.c-.html=A0)

Also, I've been having much heartburn over some of = the Deflate specifics laid out in spec wrt java's native Deflate implem= entation.
Namely:

* Java always produces= a BFINAL 1 block (looking at the openjdk source, I can see no way for BFIN= AL 0 to ever be produced).
=A0 =A0Already filed a bug with chromium folks about this (as chromium= fails to decompress if server generates a block using BFINAL 1) ...
<= div>=A0 =A0 =A0https://code.google.com/p/chromium/issues/de= tail?id=3D155060

(with Chromium hat) We'll fix it= .

That's the reason why I've added BFINAL= =3D1 options. I skimmed HyBi log and saw that Greg was talking about that l= imitation of Java.
=A0
* The various method parameters .. "s2c_max_window_bits", &q= uot;c2s_max_window_bits", "s2c_no_context_takeover", "c= 2s_no_context_takeover" are all seemingly impossible to control with t= he native Java Deflate implementations.

Please just reset your Deflate insta= nce for each message if you received s2c_no_context_takeover.
About s2c_max_window_bits, yes, you're right. I forgot to i= nvestigate if this is available on JDK.
=A0

Also, I'd like to discuss the last 2 paragraphs on = section 5.1 indicating that the client "MUST fail" the websocket = connection if these method configuration parameters are not supported. =A0C= an we get this relaxed to "MAY fail" instead? =A0Allowing the end= points to negotiate capabilities instead of failing?


It causes problem I t= hink. The server has already declared that it can accept only data compress= ed using that window size. Rather than changing the MUST to MAY, I think we= should let the client to announce it's capability by including c2s_max= _window_bits in it's method description. I.e. if there's not c2s_ma= x_window_bits token in request, the server MUST NOT request c2s_max_window_= bits. JDK based client may exclude c2s_max_window_bits.=A0

We also need to relax is the last sentence of the parag= raph defining s2c_max_window_bits.

If the
"accepted request" has this method parameter, the server M= UST
attach this method parameter with the same value as one of the
"accepted request".

Changing th= is "MUST" to "SHOULD" allows servers to reject window s= ize reduction request.

Thanks

--14dae9340673e611c804cbe9343f-- From tyoshino@google.com Fri Oct 12 21:38:54 2012 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 15C2321F8532 for ; Fri, 12 Oct 2012 21:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LeK-v3Zy8Uf for ; Fri, 12 Oct 2012 21:38:53 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5181E21F8530 for ; Fri, 12 Oct 2012 21:38:53 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so6668223iec.31 for ; Fri, 12 Oct 2012 21:38: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:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=MzcWPb4eq2XCXDNxduJjhcfQMPX+N+jn0Lx88Y5+7Xk=; b=Q24zhx+JV3PkjKarPbMLFLOAepFcE176grVirh69AJINT0b0JV73ciP7XWLfY9sK0s +hLnQcpyx7ml9DTUDW6TArvy73W6yQQ+ub5KVeasCT9tndnBye7hQSfx/ObL/lz5aGZA XWGqn7rcMdwzZLDioBzfc8A6QJ4MGFWSJ+Msla0/ShSMTyB9mpfSzdo4AFVRwj8wsVg9 pa93mPo/1hAuxXDa0orIJGguEd5bK+yHo67BK4mTdeeR5U964gXsY27DovHpSQPY3BTA xjzebE3aE5bELQNLzWWx7rKlkkL6d1mjRBHpjIU6RwIJXgXPi6/WuhmSpHg3PX8oSdyz GZNw== 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-system-of-record:x-gm-message-state; bh=MzcWPb4eq2XCXDNxduJjhcfQMPX+N+jn0Lx88Y5+7Xk=; b=ekm/RmGUO+t0XTgiMHCP522hHIjdem3Pga2VVd2b45/I1Oc5QHMotxMpZNdeJGKKs7 vf11xr+Y1jEtRKty8MczoE9qFy8VrT2840ufY2ekmTwlAuv45cf9whcVMav2Z39bvOr5 qzIpclXqVjCVhUQIu2ginfcC/CVS4fskZjRkrzavMsyxCSmpnNImQKSa0GObhgMUlF0d r3uMa47214Z88nzZQ+RN34CryeyZYzUjZ9WIfLJYjQ4YX+HKlJnvm148Q2tS/wvh8gnW 4C6SHdNjS610kOeORb56aSU3pDdSf/P1EbukqdSbW+W/SIvrwp6I2cR1wciCPGJ7wtU6 QX/A== Received: by 10.50.202.71 with SMTP id kg7mr3956128igc.55.1350103132843; Fri, 12 Oct 2012 21:38:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Fri, 12 Oct 2012 21:38:32 -0700 (PDT) In-Reply-To: References: <20121001112513.3691.55739.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Sat, 13 Oct 2012 13:38:32 +0900 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=f46d04478861a4b03904cbe9615b X-System-Of-Record: true X-Gm-Message-State: ALoCoQnjR0clLyhkryi81Zy9PxbZQIIpWAonbXOjFgbmJRUiKMRhaOJBVL/NwQEKrTuQlj7KZHuHrQxmfOgUDndpQy0AEz0UL3uqCz8YXnz+kh9L1vR2xwayVSQRZDNoMg42rPi8Q0KARZ2AShgQB9Lea7/43kbi7mRSJQIki77yhg+KYh2xbTWYq7eINSTEKQHzZ60WwOTk Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-01.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, 13 Oct 2012 04:38:54 -0000 --f46d04478861a4b03904cbe9615b Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 13, 2012 at 5:07 AM, Joakim Erdfelt wrote: > Update. > > The 2 blocks in Example 1 can be handled by Java's Deflate but the > delimiters for the block of data have to be known ahead of time. > If that example arrives as a single frame of data seen like ... > The first example in -01 is not two frame example. It's an example of two messages case (two consequent messages compressed using the same context). I'll add two frame (fragment) example in the next version. --f46d04478861a4b03904cbe9615b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 13, 2012 at 5:07 AM, Joakim Erdfelt <joakim@intalio.com&g= t; wrote:
Update.

The 2 blocks in Example 1 can be handled by Java= 's Deflate but the delimiters for the block of data have to be known ah= ead of time.
If that example arrives as a single frame of data se= en like ...

The first example in -01 is not two frame = example. It's an example of two messages case (two consequent messages = compressed using the same context).

I'll add t= wo frame (fragment) example in the next version.
--f46d04478861a4b03904cbe9615b-- From tyoshino@google.com Fri Oct 12 21:44:25 2012 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 924B521F8543 for ; Fri, 12 Oct 2012 21:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.83 X-Spam-Level: X-Spam-Status: No, score=-102.83 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tI3XWZCkIFb for ; Fri, 12 Oct 2012 21:44:25 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D350221F8691 for ; Fri, 12 Oct 2012 21:44:24 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so6671356iec.31 for ; Fri, 12 Oct 2012 21:44:24 -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:x-system-of-record; bh=NVBworRXW9Hpxv0Z3OjzeiydmAFG6gsVLoYYevF7Y7Y=; b=eQ7vuOJi4ScIHjmacaIAOqK62U0c42olZag5jUy9KeLZ1ZkM+BxybF1BSdtg4gVDje ZoYza/1+Og93/M5WbJbJPrbLRGoNJmr904NGLsGcVKfaZuV4k5CnI4sFtoSjlFn8Y7GE M9tp67GcZjN6KO5tEpmXPW6FZ8HeklKCSKpU7pwtOxjxdAuCRUf2js0Cc64KMIdtrJuh I4c2bh1Yh8gLh2aU/KSsu2V+ES5m4F+yInBypeGFVrCyR8odkWOCj/oDDfoQhedwGpXK 5zyppUGQSjIVfe1RCU+QT1cpLea7iO9O1C8KBYx4x1SJgkUocK3dhVVf58ghUyJ9+QQj 04ew== 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-system-of-record:x-gm-message-state; bh=NVBworRXW9Hpxv0Z3OjzeiydmAFG6gsVLoYYevF7Y7Y=; b=ZHyoW3QdLSN47i9Vf+n/RvAjFIqVHA9ErS42a3VswqzFYjFhtCvCLdEHp+VptnXlXJ ESNqJiNRvcwyZ+HNl7Qgnm3qEKD6InL2cDrk/C38lI+yn3h7NiZs7dDY7mYm/fni6EJh FmN4/NyUH9AMky9JdBwpmCHHDD5mGs2mUBGf1DA/4RjoY1NCCjzjzRFcYDFHxELOsjWw 54MzFRmoyJI1p8UzrOyGjG9TBtUXe/jEYtjJEH/FGSK1f1OGzPKrItQ15FADwLmft3DQ wR/PSP06a5ILUuQ68Lq9z7GvyZn2nsK7yE+GzyAKmlF3WYbTj2l7c4R2UQQdjhQOpj59 A10w== Received: by 10.50.185.200 with SMTP id fe8mr3937356igc.35.1350103464464; Fri, 12 Oct 2012 21:44:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Fri, 12 Oct 2012 21:44:03 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Sat, 13 Oct 2012 13:44:03 +0900 Message-ID: To: Gabriel Montenegro Content-Type: multipart/alternative; boundary=14dae934067368d02a04cbe9751d X-System-Of-Record: true X-Gm-Message-State: ALoCoQkS3kTHZvNpp3Wzr2RrJkCjEGVozQeOfPMT2PgG8/cChoY2P0VC8v6Lokq3Au2F2Sg1Fmmr5Anr41c8B6bwEb6GEvnF/LAHnY1oXIF/MUqWt1anyFLBGim/bBnZnbtkQnX9c+aTwzRndrfHSFwOlZ5L1dzBecCSt0KqR1wGvC+LBr0rMDJ0r8rDI+3MHptvIe5dmLla Cc: "hybi@ietf.org" Subject: Re: [hybi] "Cache-Control: no-cache" may improve handshake success rate 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, 13 Oct 2012 04:44:25 -0000 --14dae934067368d02a04cbe9751d Content-Type: text/plain; charset=ISO-8859-1 Hi, On Sat, Oct 13, 2012 at 8:10 AM, Gabriel Montenegro < Gabriel.Montenegro@microsoft.com> wrote: > Thanks, Takeshi, this is potentially low hanging fruit to obtain some > improvement. BTW, is there any number about how much improvement has been > observed or could be expected? > Yes. I want statistics, but for now the Chromium bug entry is the only report we have. When we run some live experiment next time, I'll consider adding some items to check that. --14dae934067368d02a04cbe9751d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On Sat, Oct 13, 2012 at 8:10 AM, Gabriel Monte= negro <Gabriel.Montenegro@microsoft.com> wrot= e:

Thanks, Takeshi, this is = potentially low hanging fruit to obtain some improvement.=A0 BTW, is there = any number about how much improvement has been observed or could be expected?


= Yes. I want statistics, but for now the Chromium bug entry is the only repo= rt we have.

When we run some live experiment next = time, I'll consider adding some items to check that.
=A0
--14dae934067368d02a04cbe9751d-- From joakim@intalio.com Fri Oct 12 21:51:32 2012 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 E019F21F8645 for ; Fri, 12 Oct 2012 21:51:32 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyXhmh7uI1Cq for ; Fri, 12 Oct 2012 21:51:32 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 257E221F8643 for ; Fri, 12 Oct 2012 21:51:31 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3377771pad.31 for ; Fri, 12 Oct 2012 21:51:31 -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=SnNOdyy42QxZUHCjbE8KTybaQRXeQtcBIW72voDGRBU=; b=olhS0rPhCuO8MApACOtA0gfsGG7wcyrzpEhzy4a4qvXfUX7wIHDsFaF0FFaSGdbZcN gnTLIgCTAgE5B25ncGKmM1KY2s6NL9LDxjGDP7t6Wb201ppk8nkaIkNziPuVCp6KAvup F6qCB6Ew281Q+pnvIPXH4AhUDEsCA85so0n5rimP73DiiTyeLwMFHQcnvKrMTaMyMlq0 SVQzqnQNNZtrfoH138mI0tm/Z5fjMJBxRZKwiCKHqkajFYuoAda3ZRyVLXo5g7R9gZ2x m5gj7xWI+ixUoXmCrSSc4byKgxRg1eUXA4a0xUW/jtV2t4PcC4wfqsVQoA/qN4pQ4X3u yoEg== MIME-Version: 1.0 Received: by 10.68.218.226 with SMTP id pj2mr19648790pbc.33.1350103891643; Fri, 12 Oct 2012 21:51:31 -0700 (PDT) Received: by 10.66.254.99 with HTTP; Fri, 12 Oct 2012 21:51:31 -0700 (PDT) In-Reply-To: References: <20121001112513.3691.55739.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 21:51:31 -0700 Message-ID: From: Joakim Erdfelt To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=047d7b2ed825df0b8b04cbe98ed2 X-Gm-Message-State: ALoCoQk2t/o9MjFgPkJRSvIk1IOG47E0IMLK7Ic82RJlXZsguv9kGn8furVvjp3qp48Ix1vTiCY1 Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-01.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, 13 Oct 2012 04:51:33 -0000 --047d7b2ed825df0b8b04cbe98ed2 Content-Type: text/plain; charset=ISO-8859-1 Ah. subtle. (heh. funny that 4 of us on our side missed that nuance.) I didn't have access to Greg for this (our seasoned spec whisperer), and could have used his interpretations of that bullet point. *sigh* Let me use this as suggestion to tweak / reword that first bullet point to be clear about it being 2 separate messages, 2 separate payloads, etc. Thanks again, -- Joakim Erdfelt On Fri, Oct 12, 2012 at 9:38 PM, Takeshi Yoshino wrote: > On Sat, Oct 13, 2012 at 5:07 AM, Joakim Erdfelt wrote: > >> Update. >> >> The 2 blocks in Example 1 can be handled by Java's Deflate but the >> delimiters for the block of data have to be known ahead of time. >> If that example arrives as a single frame of data seen like ... >> > > The first example in -01 is not two frame example. It's an example of two > messages case (two consequent messages compressed using the same context). > > I'll add two frame (fragment) example in the next version. > --047d7b2ed825df0b8b04cbe98ed2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ah. subtle.

(heh. funny that 4 of us on our side missed that n= uance.)

I didn't have access to Greg for this = (our seasoned spec whisperer), and could have used his interpretations of t= hat bullet point. *sigh*

Let me use this as suggestion to tweak / reword that fi= rst bullet point to be clear about it being 2 separate messages, 2 separate= payloads, etc.

Thanks again,

--
Joakim Erdfelt <joakim@intalio.com>


On Fri, Oct 12, 2012 at 9:38 PM, Takeshi= Yoshino <tyoshino@google.com> wrote:
On Sat, Oct 13, 2012 at 5:07 AM, Joakim Erdfelt <joakim= @intalio.com> wrote:
Update.

The 2 blocks in Example 1 can be handled by Java= 's Deflate but the delimiters for the block of data have to be known ah= ead of time.
If that example arrives as a single frame of data se= en like ...

The first example in -01 is not two = frame example. It's an example of two messages case (two consequent mes= sages compressed using the same context).

I'll= add two frame (fragment) example in the next version.

--047d7b2ed825df0b8b04cbe98ed2-- From internet-drafts@ietf.org Mon Oct 15 00:05:58 2012 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 3B2F621F860D; Mon, 15 Oct 2012 00:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEuD0tOgRnNH; Mon, 15 Oct 2012 00:05:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CA621F8607; Mon, 15 Oct 2012 00:05:57 -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.34 Message-ID: <20121015070557.2188.5392.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 00:05:57 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-02.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: Mon, 15 Oct 2012 07:05:58 -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 : WebSocket Per-message Compression Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-permessage-compression-02.txt Pages : 19 Date : 2012-10-15 Abstract: This specification defines a WebSocket extension that adds compression functionality to the WebSocket Protocol. It compresses the payload of non-control WebSocket messages using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each message. This specification provides one compression method available for the extension using DEFLATE. 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-permessage-compression-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Mon Oct 15 00:08:33 2012 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 CA08921F84AE for ; Mon, 15 Oct 2012 00:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.837 X-Spam-Level: X-Spam-Status: No, score=-102.837 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW4p73S0R8iZ for ; Mon, 15 Oct 2012 00:08:33 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85A0321F845F for ; Mon, 15 Oct 2012 00:08:32 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so4031451iad.31 for ; Mon, 15 Oct 2012 00:08: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 :content-type:x-system-of-record; bh=2pfHOAPFX3+SKgL0s8hubRCj7g0fTDA1NQ0xyEQK9+4=; b=nRH9aDs6Lj69BuRTj7t8mxwN8yz5KEvZDJWzVTUp431B4ioqdnFp92c0L3KHzJi9Gv goh1ekJeer+VWhkbKdzLYcNLgC1WFMOh+VOpLyXzVxS7epA+cWuYnyHss/btgf+Bus9p trNaE9hFRGRwZsssnQTTjyf/mUDL4HTN1BqVRRagG+haAf8acOj3FIWtC75Ku7CuhVwn ZmXkdcdZgbnHYwX2PgIn7fYs8ycV3ZNzo6D09KaH4npPxsAQiyeu53eRX8YkPFeJJ2B+ mVaWBJQiy4DueTXRmsu+si4BWCMrXUyAYFCiFpwPd298jiG26ZSJictygL13uHYGYBmD 3Vhg== 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-system-of-record:x-gm-message-state; bh=2pfHOAPFX3+SKgL0s8hubRCj7g0fTDA1NQ0xyEQK9+4=; b=dvGc6qg9ZLXlofBpKCDzihpVvNQ6RjA4PpEDSmEX3HdthE0cjYJ5HbX93O+xXdVfS+ 6akYAkAocZHX17X7tSeVEbL51vQaOp/WhSh/bsyGVRIYla8sEafd9epgcPvo4zzg8oJF QWFDh7ubqXXCxP9WEIZa6+O7xCQEqraPZzZYFpnSpxfSWNbq2bwtSUmzaBv0qgu1ue6w rT1RH+a6viOMrdeLYUiXHNYv6Ra8PMGZvrKN5KIYPazdbdOO6zwYd8Ds0INa0eqUbcz5 XF1+Udh0D7uem3R+HGqK551bGmsMtR+q5rG3esbwXe4TmDol2/Gf2o2a/qIg/Exwq9Fx tbdw== Received: by 10.50.219.129 with SMTP id po1mr7869276igc.35.1350284912082; Mon, 15 Oct 2012 00:08:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Mon, 15 Oct 2012 00:08:11 -0700 (PDT) In-Reply-To: <20121015070557.2188.5392.idtracker@ietfa.amsl.com> References: <20121015070557.2188.5392.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Mon, 15 Oct 2012 16:08:11 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae93410cb87bf0204cc13b4c9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnZM/8p0UQgy+kmYqvefhWNy7dpMSgTJW7w9BYnG0GjYn35dKkNSmMXIgJ/oF5bTSu/f61HPeghw9MV7w/XY+E2v6e8kYaiRFSzgDkjNS16pgGdTtM/GQF+WevlaxrN3M5hqtyhxSCF9PVPjV9MvbnnMOWUqW3eBsdnBecOlxrAr5ng9/b+v+GKDsFIMVz/FTb45nLB Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-02.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: Mon, 15 Oct 2012 07:08:33 -0000 --14dae93410cb87bf0204cc13b4c9 Content-Type: text/plain; charset=ISO-8859-1 Change from -01 to -02 is just improvement of examples section. On Mon, Oct 15, 2012 at 4:05 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 : WebSocket Per-message Compression > Author(s) : Takeshi Yoshino > Filename : draft-ietf-hybi-permessage-compression-02.txt > Pages : 19 > Date : 2012-10-15 > > Abstract: > This specification defines a WebSocket extension that adds > compression functionality to the WebSocket Protocol. It compresses > the payload of non-control WebSocket messages using specified > compression algorithm. One reserved bit RSV1 in the WebSocket frame > header is allocated to control application of compression for each > message. This specification provides one compression method > available for the extension using DEFLATE. > > 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-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-permessage-compression-02 > > > 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 > --14dae93410cb87bf0204cc13b4c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Change from -01 to -02 is just improvement of examples section.
<= br>
On Mon, Oct 15, 2012 at 4:05 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 : WebSocket Per-message Compressi= on
=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-02.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 19
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-15

Abstract:
=A0 =A0This specification defines a WebSocket extension that adds
=A0 =A0compression functionality to the WebSocket Protocol. =A0It compresse= s
=A0 =A0the payload of non-control WebSocket messages using specified
=A0 =A0compression algorithm. =A0One reserved bit RSV1 in the WebSocket fra= me
=A0 =A0header is allocated to control application of compression for each =A0 =A0message. =A0This specification provides one compression method
=A0 =A0available for the extension using DEFLATE.

=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-02

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


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

--14dae93410cb87bf0204cc13b4c9-- From tyoshino@google.com Mon Oct 15 02:07:44 2012 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 0B4DF21F865D for ; Mon, 15 Oct 2012 02:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.844 X-Spam-Level: X-Spam-Status: No, score=-102.844 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA557s1cysau for ; Mon, 15 Oct 2012 02:07:43 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3521F858F for ; Mon, 15 Oct 2012 02:07:42 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so4106651iad.31 for ; Mon, 15 Oct 2012 02:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=0CcrBfJsbm8ngBNFcXcRmPNDzqZO+RPWPJwTsu5bUs0=; b=bMwUENS4vBSGswPU0C+mejc6ZQdKcSJZAxJ9Jn3ZmIhrgg5uBbgLLtgeMLcHib4DuW Pl7KIA0GRhP4Dd+NnzBTug9yUGMHogSyfe/agzbrfOjgMEGLbXwDQinoJRw8zGIAjCIx getKsGjtvZ89m8XG1VeaQihrZfwrJ0PYqHNp3I7dl31VtfAhyQoE1d5xLDHK2+pUY6kN N20vAMHKnMnFT6O7ag4ngknYaAZUGGU3a35qnMbOrtc+1pxq4tJZbE199wNrIRr3j74a Xx6ARLGIIJSvlP6ZHPfjO3CKzDBFrSPMzipjjWcXmj50N2TA8+hG0fY6ZMexl23uzfm0 ecDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=0CcrBfJsbm8ngBNFcXcRmPNDzqZO+RPWPJwTsu5bUs0=; b=XvlCnBiUI2lGus5dHyN4cuccl9CKFAN6DBv4/5Gx3xiW9+ymhpkZVbx3iLwVu8IDAk mkF91tFhJfsgTFfs64fB2J7UQ3BX/7PhQe5D3SlRpVdHGSJ/z8KwbW6DqVqz9uTQzfU5 UspBQ+KZMEL16RjvFx3YIThRDoGrqP7cfMZFtIqInG6L7Ca0A2sWYABU9e0lLYWQ2QzY sL+nC7BCPMRWpRMt0SoNARNZL9dzlMMDUG5Cs5hmALxt/INwiFtXe29HZCGPPh5MyBv6 pFciU2ylU+n4Y8iD3L8KTDPzzS85sD05V+MoSHfw8aaRqNptkJnOpp7eaoSh5Ro67JMQ 6o3g== Received: by 10.50.106.234 with SMTP id gx10mr8270884igb.36.1350292062536; Mon, 15 Oct 2012 02:07:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Mon, 15 Oct 2012 02:07:22 -0700 (PDT) From: Takeshi Yoshino Date: Mon, 15 Oct 2012 18:07:22 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f235447bb032604cc155e5b X-System-Of-Record: true X-Gm-Message-State: ALoCoQkZJ+phESPHwWoww6ud41Pxvd3KOAShGW45HC2hg7lwd2GRIcjesuI6LwqiwKmh32MSoJrpZVJNPk3I49mDUiB1NzrS44op4GrzhfnEnBCtRLqn6VaP0yiLbDKz6+/cABUbdrnP0f1Alv6mpxDb517XGpr6/Sdeuq1pNLZo8ir8RZT1+Fya2SwZLieU3jFo25vty6cZ Subject: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter 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, 15 Oct 2012 09:07:44 -0000 --e89a8f235447bb032604cc155e5b Content-Type: text/plain; charset=ISO-8859-1 Joakim pointed out that configuring LZ77 window size is not feasible on Java in this thread http://www.ietf.org/mail-archive/web/hybi/current/msg09863.html. Sorry that this was not well considered well in the spec. My temporary proposal in this thread was: 1) allow client to control if the server may or may not use c2s_max_window_bits 2) allow server to reject s2c_max_window_bits But now I think 2) is not the best solution. Client may want to give up use of compression than accepting full-sized window. If 2) is taken, such a client needs to reestablish WebSocket connection without permessage-compress extension. Since the method parameter of permessage-compress extension can list multiple method requests, the client can choose to send method="deflate; s2c_max_window_bits=8, deflate" to tell the server that it prefers bits of 8 but it's fine with using 13, or method="deflate; s2c_max_window_bits=8" to tell the server that it really wants to use bits of 8 or fallback to no-compression mode if the server cannot. I'd like to suggest that we make only change (1. Thanks Takeshi --e89a8f235447bb032604cc155e5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joakim pointed out that configuring LZ77 window size is not feasible o= n Java in this thread=A0http://www.ietf.org/mail-archive/web/hybi/current/= msg09863.html.=A0Sorry that this was not well considered well in the sp= ec.

My temporary proposal in this thread was:
1) = allow client to control if the server may or may not use c2s_max_window_bit= s
2) allow server to reject s2c_max_window_bits

But now I think 2) is not the best solution. Client may want to = give up use of compression than accepting full-sized window. If 2) is taken= , such a client needs to reestablish WebSocket connection without permessag= e-compress extension.

Since the method parameter of permessage-compress exten= sion can list multiple method requests, the client can choose to send
=
=A0 method=3D"deflate; s2c_max_window_bits=3D8, deflate"
to tell the server that it prefers bits of 8 but it's fine with us= ing 13, or
=A0 method=3D"deflate; s2c_max_window_bits=3D8&qu= ot;
to tell the server that it really wants to use bits of 8 or f= allback to no-compression mode=A0if the server cannot.

I'd like to suggest that we make only change (1.

Thanks
Takeshi
--e89a8f235447bb032604cc155e5b-- From tyoshino@google.com Mon Oct 15 02:12:16 2012 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 98F4221F8682 for ; Mon, 15 Oct 2012 02:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.85 X-Spam-Level: X-Spam-Status: No, score=-102.85 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hC0dOs37aZj for ; Mon, 15 Oct 2012 02:12:16 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C07321F867B for ; Mon, 15 Oct 2012 02:12:15 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so4109617iad.31 for ; Mon, 15 Oct 2012 02:12: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:from:date:message-id:subject:to :content-type:x-system-of-record; bh=CE+QhE/P1aKPRyy9ejpplWCNJ/dVg4oCb5v9WlWc2dg=; b=TE0ypT5tD6vAPxaPTy7C0lNtUIWSJPSHHy8/EfgeMuoGtb7Cvna2FpGBa38eU4OqEu M2i2TgaqtPd/5nY4DNbtqHLKn97o/TV4fC3G15xMtHpxTWG+jGcyquWdd+1w4SIJReU0 +C57kHBTX5CpCNqSuuwJu8J5MNtioije9fXlGBKs2JPf1zJYkYmkLAfqA2b5hyFbniR9 7ltOxiATjsJN1N4I6p3JPXw/wkh7SkNxxl6prgJu896DKpOGFHICNHctq1p208tOqJXC CuKZm65hkWWbizBzU2g23/5OowyAV7vmkPGIkOB+WHv0LZ4AF39v1mwIPErKQ8Q2Sg4+ PV3g== 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-system-of-record:x-gm-message-state; bh=CE+QhE/P1aKPRyy9ejpplWCNJ/dVg4oCb5v9WlWc2dg=; b=nULBe3/pj4OVQmqpSEN85t53ooqu/2FElLDas0zweWA71bVNq6IsrfP9SZ6j0dQToZ OoHTQADXH9DUjQqGpPeCiLKCeL+VxSk3bFAB/5UF1SUjJPfXnNTkU9MUYoS3fQdt3mhQ 9FNRsrGbCBuW9Ae92OHY9hqt1R3GCHS9MiejZgpc+LzgiFWcw6hy+70FSq52cU04GtmU dXw1JkV+vGg9aBp8Ur4aIeFcC/22b3X7rC6DyR/lNi8SSc3OkDqrRproxEoPF+2WhK9V POVJ4qR+yt4gPz0TGLoWEXUpr6WL2htNYWn4RrvO0D8TTO216pgaxRWWIhMFBCWHK/Gi b1QA== Received: by 10.50.219.129 with SMTP id po1mr8056899igc.35.1350292335613; Mon, 15 Oct 2012 02:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Mon, 15 Oct 2012 02:11:55 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Mon, 15 Oct 2012 18:11:55 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=14dae93410cb01d74c04cc156f86 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlw2d9svmocO4EB4J4cOiE9NmatDV+UkG+gTAf0i0I7V3AETVJ1Q4mAmduw2mR6kkLXtXC0eNmSNDptvUzlIFZ5dsdbAtb3ycLuiFOgKe5MqT5CabiUjsBXUmX5JtiuCdiT90fUOAa8MSztX/AremGoKXqcOaXbJaDGURALUh4KFwHYy1dU4GpzROPVlYAudad/92Ms Subject: Re: [hybi] "Cache-Control: no-cache" may improve handshake success rate 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, 15 Oct 2012 09:12:16 -0000 --14dae93410cb01d74c04cc156f86 Content-Type: text/plain; charset=ISO-8859-1 Introduced to WebKit. https://bugs.webkit.org/show_bug.cgi?id=98000 --14dae93410cb01d74c04cc156f86 Content-Type: text/html; charset=ISO-8859-1
Introduced to WebKit.
https://bugs.webkit.org/show_bug.cgi?id=98000

--14dae93410cb01d74c04cc156f86-- From simone.bordet@gmail.com Mon Oct 15 03:30:50 2012 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 DBF3621F86CA for ; Mon, 15 Oct 2012 03:30:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajsAQhr+RzsT for ; Mon, 15 Oct 2012 03:30:50 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A08521F86B2 for ; Mon, 15 Oct 2012 03:30:50 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so4159480iad.31 for ; Mon, 15 Oct 2012 03:30:49 -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=pS6w5ljn6efqVE2PmvzwJboqbGeEWNuYicaBoQqGMfw=; b=iTgYUkxIA05fFP8IZVYMoRIAvtYxZ1ZCs6PCrRWzPqK8+LEShMLjMhR75HNHMYHzMt 51EqiEL1tgHLWuPLcF2rMnanwdS+DTcgHY3O+nK52Dko2sCnw6NA5CTRotuGRjfaTxMi lnGixebyCrNqNVPhwFavaV+0DWOhct9QheN/znpl17U32WR+BasK7IY8IKXyb+Ra1IcG T/a4NolgcqNeAC7kKTOqplnCjPbTKHRX21K1yM2a7eRz/dvOkz2K83Jr9eMB/47ZIMzN xAGhgcFdvQQUunTd2PQJ7KAYJiXOSFplTUXj5tnnN7r0u1CNDQ67R9bC3CJKkiEvhxNE PcUQ== MIME-Version: 1.0 Received: by 10.50.185.200 with SMTP id fe8mr8160313igc.35.1350297049513; Mon, 15 Oct 2012 03:30:49 -0700 (PDT) Received: by 10.64.147.100 with HTTP; Mon, 15 Oct 2012 03:30:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Oct 2012 12:30:49 +0200 Message-ID: From: Simone Bordet To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Cc: hybi@ietf.org Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter 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, 15 Oct 2012 10:30:51 -0000 Hi, On Mon, Oct 15, 2012 at 11:07 AM, Takeshi Yoshino wrote: > Joakim pointed out that configuring LZ77 window size is not feasible on Java > in this thread > http://www.ietf.org/mail-archive/web/hybi/current/msg09863.html. Sorry that > this was not well considered well in the spec. > > My temporary proposal in this thread was: > 1) allow client to control if the server may or may not use > c2s_max_window_bits > 2) allow server to reject s2c_max_window_bits > > But now I think 2) is not the best solution. Client may want to give up use > of compression than accepting full-sized window. If 2) is taken, such a > client needs to reestablish WebSocket connection without permessage-compress > extension. > > Since the method parameter of permessage-compress extension can list > multiple method requests, the client can choose to send > method="deflate; s2c_max_window_bits=8, deflate" > to tell the server that it prefers bits of 8 but it's fine with using 13, or > method="deflate; s2c_max_window_bits=8" > to tell the server that it really wants to use bits of 8 or fallback to > no-compression mode if the server cannot. > > I'd like to suggest that we make only change (1. May I ask what is the use case for supporting window sizes different from 32k ? I ask because I think it complicates the specification quite a bit (number of test cases, checks whether the value is between 8 and 15, etc.), small windows have proved to lead to bad compression, and to my knowledge 32k is the window size that I have seen used everywhere (but then again, I am a server guy). Takeshi, do you have empirical data that shows that usages of window sizes different from 32k is widespread and hence needs to be supported ? Given the current size and trend for memory of embedded devices, I am dubious windows less than 32k will ever be used, but I'll be happy to be corrected. Also, it is my understanding that the compressor needs eventually to specify the window size to the library before compressing, but the decompressor will just work with any window size. If that holds true, what is the reason to tell the remote endpoint what window is being used ? Thanks ! Simon -- http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From SRS0+237b20beab98f06c=IM=noemax.com=arman@noemax.com Mon Oct 15 04:15:08 2012 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 24EB321F86D0 for ; Mon, 15 Oct 2012 04:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90AwDRGVdoVe for ; Mon, 15 Oct 2012 04:15:07 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id C70FB21F86B6 for ; Mon, 15 Oct 2012 04:15:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1350299710; x=1350904510; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=0Z30IpNcmvrHyADDPhXaQw5G0nk=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References; b=xcn7LsOM62tdo+/mxHx0sQtqAuC8qMaKRM5dDgRvcGOHWt/pXSi6u7XmDP2VMXrlGFjEnRV3fWIQFTNoZcg+1Th2+NKg/2FIyW3aJ8tt06JbnTsMb5aNzcC3IkG5ZgY8llClTydPmChITzm3T/x5RuVI/iGmqnNs9s/SzZd+Ps8= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.3) with ASMTP (SSL) id ZVE10409; Mon, 15 Oct 2012 14:15:09 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , References: In-Reply-To: Date: Mon, 15 Oct 2012 14:14:57 +0300 Message-ID: <001501cdaac6$52192ac0$f64b8040$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CDAADF.7768D3C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGrGEObTRLSBGYgP6AO/33GaQznV5f/W+PA Content-Language: en-us Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter 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, 15 Oct 2012 11:42:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0016_01CDAADF.7768D3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reposting to the proper thread. The benefit of using an asymmetric configuration with the DEFLATE algorithm is very small. It would be OK if there is no negotiation of the window size. In general, providing the ability to configure the window size is of limited benefit while it increases complexity, so another option is to entirely remove the sliding window size parameters and use a default value in every case. With best regards, Arman From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Monday, October 15, 2012 12:07 PM To: hybi@ietf.org Subject: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter Joakim pointed out that configuring LZ77 window size is not feasible on Java in this thread http://www.ietf.org/mail-archive/web/hybi/current/msg09863.html. Sorry that this was not well considered well in the spec. My temporary proposal in this thread was: 1) allow client to control if the server may or may not use c2s_max_window_bits 2) allow server to reject s2c_max_window_bits But now I think 2) is not the best solution. Client may want to give up use of compression than accepting full-sized window. If 2) is taken, such a client needs to reestablish WebSocket connection without permessage-compress extension. Since the method parameter of permessage-compress extension can list multiple method requests, the client can choose to send method="deflate; s2c_max_window_bits=8, deflate" to tell the server that it prefers bits of 8 but it's fine with using 13, or method="deflate; s2c_max_window_bits=8" to tell the server that it really wants to use bits of 8 or fallback to no-compression mode if the server cannot. I'd like to suggest that we make only change (1. Thanks Takeshi ------=_NextPart_000_0016_01CDAADF.7768D3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reposting to the proper thread.

 

The benefit of using an asymmetric configuration with the DEFLATE = algorithm is very small. It would be OK if there is no negotiation of = the window size.

 

In general, providing the ability to configure the window size is of = limited benefit while it increases complexity, so another option is to = entirely remove the sliding window size parameters and use a default = value in every case.

 

With best regards,

Arman

 

 

From: = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino
Sent: Monday, October 15, 2012 12:07 = PM
To: hybi@ietf.org
Subject: [hybi] Allow client to = control that the server may or may not use c2s_max_window_bits extension = parameter

 

Joakim = pointed out that configuring LZ77 window size is not feasible on Java in = this thread = http://www.ietf.org/mail-archive/web/hybi/current/msg09863.html. = ;Sorry that this was not well considered well in the = spec.

 

My temporary proposal in this thread = was:

1) allow client to = control if the server may or may not use = c2s_max_window_bits

2) = allow server to reject s2c_max_window_bits

 

But now I think 2) is not the best solution. Client = may want to give up use of compression than accepting full-sized window. = If 2) is taken, such a client needs to reestablish WebSocket connection = without permessage-compress extension.

 

Since the method parameter of permessage-compress = extension can list multiple method requests, the client can choose to = send

  = method=3D"deflate; s2c_max_window_bits=3D8, = deflate"

to tell the = server that it prefers bits of 8 but it's fine with using 13, = or

  = method=3D"deflate; = s2c_max_window_bits=3D8"

to tell the server that it really wants to use bits of = 8 or fallback to no-compression mode if the server = cannot.

 

I'd like to suggest that we make only change = (1.

 

Thanks
Takeshi

------=_NextPart_000_0016_01CDAADF.7768D3C0-- From SRS0+237b20beab98f06c=IM=noemax.com=arman@noemax.com Mon Oct 15 04:13:42 2012 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 F0FB321F866B for ; Mon, 15 Oct 2012 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez9gB9Dkz1Mu for ; Mon, 15 Oct 2012 04:13:41 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2AC21F8628 for ; Mon, 15 Oct 2012 04:13:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1350299624; x=1350904424; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=mm36Jf/lNOFNsu0DRWVg2HudEs0=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=p8IzgUydc/i+nzF+5tGQHCQUcjdtGZZcYGk3ut9RY4Bqcz3/vUPyLQI+9GCfUvXKOdp7iAPWTS0uLhzUmry2aKGx+fWTkcz6eZcqlUP6unkeQUvNWWVRzhEBGoCyZHZbe1oJCKcRgy/LOanoE1yjTw+kkz2EY2QuoY1w/15wxk4= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.3) with ASMTP (SSL) id ZVC40043; Mon, 15 Oct 2012 14:13:43 +0300 From: "Arman Djusupov" To: "'Simone Bordet'" , "'Takeshi Yoshino'" References: In-Reply-To: Date: Mon, 15 Oct 2012 14:13:31 +0300 Message-ID: <001401cdaac6$1f037820$5d0a6860$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGrGEObTRLSBGYgP6AO/33GaQznVwH7PY1Al++BZnA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter 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, 15 Oct 2012 11:42:15 -0000 The decompressor must use a window size that is larger or equal to the compressor's window size. If the decompressor's window size is smaller than the one used by the compressor, then the decompressor cannot resolve references that are outside its window. With best regards, Arman -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Simone Bordet Sent: Monday, October 15, 2012 1:31 PM To: Takeshi Yoshino Cc: hybi@ietf.org Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter Also, it is my understanding that the compressor needs eventually to specify the window size to the library before compressing, but the decompressor will just work with any window size. If that holds true, what is the reason to tell the remote endpoint what window is being used ? Thanks ! Simon -- http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From simone.bordet@gmail.com Mon Oct 15 07:36:32 2012 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 1BDE921F8786 for ; Mon, 15 Oct 2012 07:36:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJzvHPMxvd7f for ; Mon, 15 Oct 2012 07:36:31 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A06621F8747 for ; Mon, 15 Oct 2012 07:36:31 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so9191210iec.31 for ; Mon, 15 Oct 2012 07:36:30 -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=TD6/Xb+qnZiyBBVUG9b7Z4bhuxyoBUC0ok+dG5vO6Zc=; b=oKjF4SMZ59VS55kD/HF3Kgew4v9aD83C6Lum9++nxR+r9LJ+9Ayd+ZgPajTZtdFp6K QggFscGS0+0IJaxMCZm2T63vjJj4C/nNPT3qFnIvGWWqwE98pbLGOznzl64Nb1LWeTzY I57iRiqLh5Zfy/Bs0PELd+oEd/cY1ubSGyTlCZeL9jsRtc1RigNmBnwrNDOakhMszPi0 kQolbtqdNhxqldZ7yl5vT7+IOGbsVSZXsO+6rCTxGFvDDvF+U8xXTkkaQ3jJN03ykyG4 pRcA5ftBdFIByd9nqnkm50uCZY5nCwKcClcan8/Zbu+Rvd04EIdvED6qTup4UTsUqttQ MuRQ== MIME-Version: 1.0 Received: by 10.50.213.1 with SMTP id no1mr8904256igc.64.1350311790867; Mon, 15 Oct 2012 07:36:30 -0700 (PDT) Received: by 10.64.147.100 with HTTP; Mon, 15 Oct 2012 07:36:30 -0700 (PDT) In-Reply-To: <001501cdaac6$52192ac0$f64b8040$@noemax.com> References: <001501cdaac6$52192ac0$f64b8040$@noemax.com> Date: Mon, 15 Oct 2012 16:36:30 +0200 Message-ID: From: Simone Bordet To: Arman Djusupov Content-Type: text/plain; charset=UTF-8 Cc: hybi@ietf.org Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter 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, 15 Oct 2012 14:36:32 -0000 Hi, On Mon, Oct 15, 2012 at 1:14 PM, Arman Djusupov wrote: > Reposting to the proper thread. > > > > The benefit of using an asymmetric configuration with the DEFLATE algorithm > is very small. It would be OK if there is no negotiation of the window size. > > > > In general, providing the ability to configure the window size is of limited > benefit while it increases complexity, so another option is to entirely > remove the sliding window size parameters and use a default value in every > case. I'm +1 for removing the sliding window size parameters and defaulting to 32k. Devices that need to run with incredibly small memory requirements may write their own extension, either with a different algorithm, or with a smaller window size that is implicitly agreed by both client and server (e.g. calling the extension "deflate-8" for 8 bits window size). I'm guessing that if the device can run a browser, then a 32k window is ok. Is there evidence from mobile browser vendors that this is not the case ? Thanks ! Simon -- http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From tyoshino@google.com Mon Oct 15 09:25:57 2012 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 6F9CD21F86C3 for ; Mon, 15 Oct 2012 09:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6VSoLFHUrAy for ; Mon, 15 Oct 2012 09:25:56 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E51E21F86C4 for ; Mon, 15 Oct 2012 09:25:56 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so4005457lam.31 for ; Mon, 15 Oct 2012 09:25:55 -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:x-system-of-record; bh=4ZYHGWfXvUkdreyRPB7anUZnT1LWZt8FRoO2Ugom0Y0=; b=mXGdW7K1D0Hv+de6NcZt2TPF3YD2oIHBLkDk0u+4JOvvEJaSmPBIFEL8M+X0zo2o7E 6JmEaCtAPiwMugo41fk0PzDWvOGMDPOrdtzkXch6tQ+te+3AySanNjXKbrQuhrw3Ex2G PEdOE8zOWkjxSgzDeX//rFmb0YMewQAhsPwi643x6T9MiwitPNKn/r2DPcerQQAEe7Ai RlBw3LZV1Rlw+hdSU1ox/SYwpQFDCf9LsaMFO86XnUzRMtPiiahKjU0ELhSwI0uJ9yWA K/4MFHSQkN5+VTrRe1gfhBHaIKq/Hrikt4WExkP97HWOm0deIK/u1jX6V5WVoSvLUhKt NSaQ== 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-system-of-record:x-gm-message-state; bh=4ZYHGWfXvUkdreyRPB7anUZnT1LWZt8FRoO2Ugom0Y0=; b=BSDxwkNSoROdKeFqxPbJZEvIpAtvFbDj8FOtn1QnW6FUPcEllr/cWhVDS9zcg22JYc e8bdSbL/1SNWqck7xaNgd4A+UG2dTEdOBPS2L+mq0aD4TX3uPywazp5EpnCJmXCRsxLB I5UKZnhcA2ziDRuaTI8qeukahFQt7HV7esXMuA0nj9cZeQ7XxE2tfzZSqp/8iNbT99Hp Gh1S6dVlsJsT2Yavk9QggOCt/QYNCD6+TnU0XTTxE1Gm6bH0N1SnrDw8/il5ZwL7m78K F5EPKMaTHuxRjZmd8blxHXBZImDhjYvLg0SoGdo7Uo/kA910pRFBA6bX5e+BJQxGCwD7 /hww== Received: by 10.152.110.74 with SMTP id hy10mr10499846lab.54.1350318355241; Mon, 15 Oct 2012 09:25:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.44.131 with HTTP; Mon, 15 Oct 2012 09:25:34 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 16 Oct 2012 01:25:34 +0900 Message-ID: To: Simone Bordet Content-Type: multipart/alternative; boundary=bcaec54ee8c8e5da0a04cc1b7dcd X-System-Of-Record: true X-Gm-Message-State: ALoCoQmvIfn+0R7TIXkreIrZysdLj6AJJfEB3KpLZGw+wYe2SmDIs6iz+7yX6R5cmfh+aoFlCmHu+YOARZXiHNPrmJRwNs3SpbPOA71SUxAgcQPTVlmonkCRqHg+fpqXGtLwsSTZwr5UNK2QfpVNc3Ec6bG82rfkh2zi7QfjXSR3l5F6ntRB3s7j+mxa0y8GwZkcyK9pWotA Cc: hybi@ietf.org Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter 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, 15 Oct 2012 16:25:57 -0000 --bcaec54ee8c8e5da0a04cc1b7dcd Content-Type: text/plain; charset=ISO-8859-1 Hi Simone, On Mon, Oct 15, 2012 at 7:30 PM, Simone Bordet wrote: > May I ask what is the use case for supporting window sizes different from > 32k ? > > I ask because I think it complicates the specification quite a bit > (number of test cases, checks whether the value is between 8 and 15, > etc.), small windows have proved to lead to bad compression, and to my > knowledge 32k is the window size that I have seen used everywhere (but > then again, I am a server guy). > > Takeshi, do you have empirical data that shows that usages of window > sizes different from 32k is widespread and hence needs to be supported > ? > > I thought that when we use lots of long-lived WebSocket sessions and each of them uses the same compression context for all messages, memory pressure of compression context (40k * number of connections when bits=15 all the time even if they're idle for most of time, while HTTP requires 40k * number of response messages received simultaneously on the server) will be problematic for servers handling hundreds of connections. That's the reason I've added this option to allow the server side to ask the client side to use smaller window size. s2c_max_window_size was added as a bonus considering embedded systems. This is the post where I proposed addition of these parameters. The John's post referred in this post suggested that window bits of 10-11 is recommended and sufficient. http://www.ietf.org/mail-archive/web/hybi/current/msg07935.html But as shown on this post, the difference is not so big. zlib decompressor needs 10k for bits=8, 10k for bits=10 and 40k for bits=15. Just ~4 times. http://www.ietf.org/mail-archive/web/hybi/current/msg07980.html Comments are welcome. Please let me know your thoughts on trade-off between flexibility of window size and complexity of negotiation. > Given the current size and trend for memory of embedded devices, I am > dubious windows less than 32k will ever be used, but I'll be happy to > be corrected. > > Also, it is my understanding that the compressor needs eventually to > specify the window size to the library before compressing, but the > decompressor will just work with any window size. > These options are to allow an endpoint to reduce the size of memory to be allocated for its decompressor by telling the other side the window size to use for its decompressor in advance. 32kB decompressor works for any data. 256B decompressor works only for data compressed using 256B window as Arman already answered. > If that holds true, what is the reason to tell the remote endpoint > what window is being used ? > --bcaec54ee8c8e5da0a04cc1b7dcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Simone,

On Mon, Oct 15, 2012 at 7:30 = PM, Simone Bordet <simone.bordet@gmail.com> wrote:
=
May I ask what is the use case for supporting window sizes different from 3= 2k ?

I ask because I think it complicates the specification quite a bit
(number of test cases, checks whether the value is between 8 and 15,
etc.), small windows have proved to lead to bad compression, and to my
knowledge 32k is the window size that I have seen used everywhere (but
then again, I am a server guy).

Takeshi, do you have empirical data that shows that usages of window
sizes different from 32k is widespread and hence needs to be supported
?


I thought that when we use lots of lon= g-lived WebSocket sessions and each of them uses=A0the same compression con= text for all messages, memory pressure of compression context (40k * number= of connections when bits=3D15 all the time even if they're idle for mo= st of time,=A0while HTTP requires 40k * number of response messages receive= d simultaneously on the server) will be problematic for servers handling hu= ndreds of connections. That's the reason I've added this option to = allow the server side to ask the client side to use smaller window size. s2= c_max_window_size was added as a bonus considering embedded systems.

This is the post where I proposed addition of these par= ameters. The John's post referred in this post suggested that window bi= ts of 10-11 is recommended and sufficient.

But as shown on this post, the difference is not so big= . zlib decompressor needs 10k for bits=3D8, 10k for bits=3D10 and 40k for b= its=3D15. Just ~4 times.

Comments are welcome. Please let me know your thoughts = on trade-off between flexibility of window size and complexity of negotiati= on.
=A0
Given the current size and trend for memory of embedded devices, I am
dubious windows less than 32k will ever be used, but I'll be happy to be corrected.

Also, it is my understanding that the compressor needs eventually to
specify the window size to the library before compressing, but the
decompressor will just work with any window size.

=
These options are to allow an endpoint to reduce the size of mem= ory to be allocated for its decompressor by telling the other side the wind= ow size to use for its decompressor in advance.

32kB decompressor works for any data. 256B decompressor= works only for data compressed using 256B window as Arman already answered= .
=A0
If that holds true, what is the reason to tell the remote endpoint
what window is being used ?
=A0
--bcaec54ee8c8e5da0a04cc1b7dcd-- From simone.bordet@gmail.com Mon Oct 15 11:39:07 2012 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 418AE21F8882 for ; Mon, 15 Oct 2012 11:39: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgokCFqBS6O7 for ; Mon, 15 Oct 2012 11:39:06 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC0A21F8806 for ; Mon, 15 Oct 2012 11:39:06 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so9683401iec.31 for ; Mon, 15 Oct 2012 11:39: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; bh=oDSTkwHgeDmfdM4WXkD563Vq/veqW9FsG4QQk33sZT4=; b=CVP+R1HDrTOdVLLfsimeaRQG+CPjl1VcNDHSHqFPqdtzB7VUqKtXqJrS7tiCY9kF7Q 8AuPDM0oZwZOgFVoOzxFuG4AelMJBug+pDO4VyRKrZnanaYWIhJFKD/gc87aYVyx5aRj Rl9cpfT2KX9YFdlX5nYmppxmBY5C9B7olGOPW7jskwqPSA/w9P9u2WsbIRY9bzJfc3zK g686jZUaDNTqXGV/HKI8dhO3+ubKh5u0f/A4lsCeXNFKUz08CIVdqhvi0ju+HrG3quu0 4/DI6Ykr5ye4137fFZEBQQL7orylaUFbg1R4Z6W37WJ6GgtE1gRWtNN8LNmWX8cWueMW AvbA== MIME-Version: 1.0 Received: by 10.50.212.8 with SMTP id ng8mr9590798igc.64.1350326346233; Mon, 15 Oct 2012 11:39:06 -0700 (PDT) Received: by 10.64.147.100 with HTTP; Mon, 15 Oct 2012 11:39:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Oct 2012 20:39:05 +0200 Message-ID: From: Simone Bordet To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Cc: hybi@ietf.org Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter 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, 15 Oct 2012 18:39:07 -0000 Hi, On Mon, Oct 15, 2012 at 6:25 PM, Takeshi Yoshino wrote: > I thought that when we use lots of long-lived WebSocket sessions and each of > them uses the same compression context for all messages, memory pressure of > compression context (40k * number of connections when bits=15 all the time > even if they're idle for most of time, while HTTP requires 40k * number of > response messages received simultaneously on the server) will be problematic > for servers handling hundreds of connections. That's the reason I've added > this option to allow the server side to ask the client side to use smaller > window size. That is true if all connections are compressed, which may not be the case. Furthermore, browsers/clients will eventually implement MUX, reducing the number of connections needed towards a single server. I guess that's the reason why this was never a much discussed problem in SPDY, although attention has been paid to it. > s2c_max_window_size was added as a bonus considering embedded > systems. > > This is the post where I proposed addition of these parameters. The John's > post referred in this post suggested that window bits of 10-11 is > recommended and sufficient. > http://www.ietf.org/mail-archive/web/hybi/current/msg07935.html > > But as shown on this post, the difference is not so big. zlib decompressor > needs 10k for bits=8, 10k for bits=10 and 40k for bits=15. Just ~4 times. > http://www.ietf.org/mail-archive/web/hybi/current/msg07980.html > > Comments are welcome. Please let me know your thoughts on trade-off between > flexibility of window size and complexity of negotiation. There are 4 parameters for the deflate method, which makes 16 test cases and 16 branches in the implementations to take care of the various cases (valid and errors). I already imagine implementations taking shortcuts to avoid to cope with all cases, or just because they cannot easily set those parameters, e.g. for lack of library support. FTR, window size and mem_level are not settable in Java (defaulting to 15 bits and 8, respectively) without resorting to external, native libraries. The JEE space is standardizing the server-side Java API for WebSocket, so eventually there will be JEE web applications using WebSocket like now there are Servlets (i.e. a lot). I asked for data evidence because while I understand the need for flexibility, if only 0.01% of applications using deflate use a window size different from 32k, then perhaps it's not worth, and as I said, there is always the possibility to write a custom extension for e.g. embedded devices. Thanks ! Simon -- http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From ibc@aliax.net Mon Oct 15 12:50:33 2012 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 5CEAD21F8949 for ; Mon, 15 Oct 2012 12:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkmaZ0lzFp-p for ; Mon, 15 Oct 2012 12:50:32 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A57C221F8932 for ; Mon, 15 Oct 2012 12:50:31 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so4163582lam.31 for ; Mon, 15 Oct 2012 12:50:30 -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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=IhJO25W3twe7+BMgiGm7ZazcGufIfqlYJOn2xZeQMXs=; b=nQ7SmyDVIc+/Ei1khD+UeZpzVQf6nPFsRRQBVmfEtttCtDI2IllM5WmtOiy4qqbF34 5+mKUxFwqxtvdEnJVPuLHauOwtRHTjHNg/Xx1j8kYnIGxK93UrBoQnOxigZ1O1OYwyM6 5c+eITyBNSc63nOIP1QN1AdzFqgN6M8NblvuCGkKFl4K8UEXbgZBhaLrQPor6qzXR4F+ /Sf+DdI9KYUVQSVH6Zj1UAmGh3DzfOwGfz/BXuqffzKdNE1S9l2/FD8lMePSo5iKUuEg 6RToEhrpm5Qfov7tuX+u06bv8qRBTt5o9re9HuKqGEsFAg3qXqlgYGN8bBSzO5E3BDEp 07Fw== Received: by 10.152.103.100 with SMTP id fv4mr10758234lab.39.1350330630508; Mon, 15 Oct 2012 12:50:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.26.37 with HTTP; Mon, 15 Oct 2012 12:50:10 -0700 (PDT) In-Reply-To: <71636B367FF5B74F8C75E6998C03546A34E0678E@SINEX14MBXC405.southpacific.corp.microsoft.com> References: <71636B367FF5B74F8C75E6998C03546A34E0678E@SINEX14MBXC405.southpacific.corp.microsoft.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 15 Oct 2012 21:50:10 +0200 Message-ID: To: "Prashant Mahajan (Icertis Inc)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmevwNEJO/Tv4p8G64sdxpvZPpvrHuWpH8DmME/m34L92JaPOFkxV76+h1DAlh2oytHiiN3 Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSocket Protocol 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, 15 Oct 2012 19:50:33 -0000 2012/10/11 Prashant Mahajan (Icertis Inc) : > I am a newcomer developer for HTML5. From the articles what I got is, the > real use of Web Socket protocol is in IM application. Am I right? Hi, please read the full spec: http://tools.ietf.org/html/rfc6455 --=20 I=C3=B1aki Baz Castillo From tyoshino@google.com Mon Oct 15 19:31:26 2012 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 7952921F87C1 for ; Mon, 15 Oct 2012 19:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnwiudKSz5sR for ; Mon, 15 Oct 2012 19:31:25 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4743221F87AE for ; Mon, 15 Oct 2012 19:31:24 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so10376812iec.31 for ; Mon, 15 Oct 2012 19:31:23 -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:x-system-of-record; bh=GivsjgHB5PPt5oXNWmJwa49+yy9bzIu2Cg08gk7P7XA=; b=kAyznzKRh9kfJ+VqJXsr/g7HmVsigAIio7zZcC2Nsg2X0HvFAd7BZTKl8jaJuAgjLC ybNTd/5Ksh/WE99THbDd93Tk1/wnqC62H2U1xFAY0ALHW7bwy0xwkIZjfUG6moYTmtkv jAu4bet1ETTG4SVcxuhjzJBfxrBbQRCGaeEIP8wTxCTryhdR+pDdA0boOaHfN21F+7pj sHUJzApX/EIuKJNdV9+fdhsv+VrUtwbp99s6KtrIVl5PMOvs3farlag6+xfe6WXDr6uO TxM+KIEIAWtK3tnW4FXJrDQ+h3F7zw98C7263lhjJOP9SEO3UGcaT7kjX1Wn0IDm591z MZuA== 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-system-of-record:x-gm-message-state; bh=GivsjgHB5PPt5oXNWmJwa49+yy9bzIu2Cg08gk7P7XA=; b=h9pL7ZdoHTiUPbr/PlXIPP5ymAUv6CaW0U13Dbpjm26W9ADeYGW27bA3nX50axJves +yc8nGmyNGfXjrrQ6/1GG35hQf8WGXCcn83Mv7Df3AMV0ResceRwk+EVZVySq57EO4wm rX4v3MZIEWxzt3ZqTsz8PDfftyeYNYG5649QYLc2b4V9ZuvT9DpiRGAkbTSG/1FByneM Y33jBb0icTVoWKlfpwRjWHAsc7dqqQkndLPGrJExlYXFwYfRuwA27lvToVUJWNCZP27j ngEUXeM+W2vNWr8LEW3N+FPynf2MXJ3PZY3BiQCVa9lP2kb0jDC8Ruqxvpj3zkRTKC0w Zj5w== Received: by 10.50.183.199 with SMTP id eo7mr4773259igc.36.1350354683614; Mon, 15 Oct 2012 19:31:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Mon, 15 Oct 2012 19:31:03 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 16 Oct 2012 11:31:03 +0900 Message-ID: To: Simone Bordet Content-Type: multipart/alternative; boundary=14dae934042d3cd78404cc23f358 X-System-Of-Record: true X-Gm-Message-State: ALoCoQny9R/X+hmYaQFZnTWEclEzVOZBy6J3OwCF7Nw8EcZfY5zZjKLd7d/xMpPm/vAauFxcPbhp0v5lbmduOosiGT3M5Pw19byrXs5D64qVRgtFT0m5oG+fAxWQptgGLQ7mYa6r8EZXz5ZWIg8FKRyVj88NWgVmloabCOtfoGaSFkhK8VdAoxAMoUv6vqAnduiJ1CwEoA/h Cc: hybi@ietf.org Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter 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, 16 Oct 2012 02:31:26 -0000 --14dae934042d3cd78404cc23f358 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Tue, Oct 16, 2012 at 3:39 AM, Simone Bordet wrote: > Hi, > > On Mon, Oct 15, 2012 at 6:25 PM, Takeshi Yoshino > wrote: > > I thought that when we use lots of long-lived WebSocket sessions and > each of > > them uses the same compression context for all messages, memory pressure > of > > compression context (40k * number of connections when bits=15 all the > time > > even if they're idle for most of time, while HTTP requires 40k * number > of > > response messages received simultaneously on the server) will be > problematic > > for servers handling hundreds of connections. That's the reason I've > added > > this option to allow the server side to ask the client side to use > smaller > > window size. > > That is true if all connections are compressed, which may not be the case. > Right. The server can choose which connection to use compression. The ratio of compression enabled logical channel per web app might be small. > Furthermore, browsers/clients will eventually implement MUX, reducing > the number of connections needed towards a single server. > Even with multiplexing, each logical channel spends memory for its compression context. Because of concern with CRIME attack, I've added a text to discourage use of compression to output of multiplexing. It's true that multiplexing reduces the total amount of memory (e.g. kernel resource for TCP) per logical connection (= number of WebSocket instances) and it might make memory consumption for compression context affordable. There are 4 parameters for the deflate method, which makes 16 test > cases and 16 branches in the implementations to take care of the > various cases (valid and errors). > I already imagine implementations taking shortcuts to avoid to cope > with all cases, or just because they cannot easily set those > parameters, e.g. for lack of library support. > > After taking in the change I've proposed in this thread in response to Joakim, s2c_max_window_size and c2s_max_window_size become optional feature. - Client implementors can choose not to send c2s_max_window_size to skip implementing c2s_max_window_size. - Server implementors can choose not to accept request w/ s2c_max_window_size to skip implementing it. As a result, these specs might be ignored by most of implementors as you said, but we can keep these options available for people who want them. So, the problem is complexity of the spec document. I'll try to make the spec less complicated and these options look optional clearly. If it turned out to be hard to do so, I'll just remove these texts. Please give me 1 day. Thanks --14dae934042d3cd78404cc23f358 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On Tue, Oct 16, 2012 at 3:39 AM, Simone Bordet <simone.bordet@gmail.com> wrote:
Hi,

On Mon, Oct 15, 2012 at 6:25 PM, Takeshi Yoshino <tyoshino@google.com> wrote:
> I thought that when we use lots of long-lived WebSocket sessions and e= ach of
> them uses the same compression context for all messages, memory pressu= re of
> compression context (40k * number of connections when bits=3D15 all th= e time
> even if they're idle for most of time, while HTTP requires 40k * n= umber of
> response messages received simultaneously on the server) will be probl= ematic
> for servers handling hundreds of connections. That's the reason I&= #39;ve added
> this option to allow the server side to ask the client side to use sma= ller
> window size.

That is true if all connections are compressed, which may not be the = case.

Right. The server can choose whic= h connection to use compression. The ratio of compression enabled logical c= hannel per web app might be small.
=A0
Furthermore, browsers/clients will eventually implement MUX, reducing
the number of connections needed towards a single server.
<= div>
Even with multiplexing, each logical channel spends memo= ry for its compression context. Because of concern with CRIME attack, I'= ;ve added a text to discourage use of compression to output of multiplexing= .

It's true that multiplexing reduces the total amoun= t of memory (e.g. kernel resource for TCP) per logical connection (=3D numb= er of WebSocket instances) and it might make memory consumption for compres= sion context affordable.

There are 4 parameters for th= e deflate method, which makes 16 test
cases and 16 branches in the implementations to take care of the
various cases (valid and errors).
I already imagine implementations taking shortcuts to avoid to cope
with all cases, or just because they cannot easily set those
parameters, e.g. for lack of library support.


After taking in the change I've pr= oposed in this thread in response to Joakim, s2c_max_window_size and c2s_ma= x_window_size become =A0optional feature.

- Client= implementors can choose not to send c2s_max_window_size to skip implementi= ng c2s_max_window_size.
- Server implementors can choose not to accept request w/ s2c_max_wind= ow_size to skip implementing it.

As a result, thes= e specs might be ignored by most of implementors as you said, but we can ke= ep these options available for people who want them.

So, the problem is complexity of the spec document. I&#= 39;ll try to make the spec less complicated and these options look optional= clearly. If it turned out to be hard to do so, I'll just remove these = texts. Please give me 1 day.

Thanks
=A0
--14dae934042d3cd78404cc23f358-- From internet-drafts@ietf.org Mon Oct 15 23:19:59 2012 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 5BDD521F88F3; Mon, 15 Oct 2012 23:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO2T+rVYGpI0; Mon, 15 Oct 2012 23:19:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D861B21F88F4; Mon, 15 Oct 2012 23:19:58 -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.34 Message-ID: <20121016061958.24942.45385.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 23:19:58 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-03.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, 16 Oct 2012 06:19:59 -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 : WebSocket Per-message Compression Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-permessage-compression-03.txt Pages : 20 Date : 2012-10-15 Abstract: This specification defines a WebSocket extension that adds compression functionality to the WebSocket Protocol. It compresses the payload of non-control WebSocket messages using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each message. This specification provides one compression method available for the extension using DEFLATE. 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-permessage-compression-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Mon Oct 15 23:27:35 2012 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 3F04B21F8938 for ; Mon, 15 Oct 2012 23:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.845 X-Spam-Level: X-Spam-Status: No, score=-102.845 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4MPeC+-sKDI for ; Mon, 15 Oct 2012 23:27:34 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8143121F8888 for ; Mon, 15 Oct 2012 23:27:33 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so10629987iec.31 for ; Mon, 15 Oct 2012 23:27:33 -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:x-system-of-record; bh=k98xqsw3P8D0qyqKkOjZP6DYUcNrktN3ZIdlIHtKMSw=; b=U4xbRC1lT2Q6p17WMTzhf7LK7UiQUfn1E6SJZe1nqJkW2XAl71boGx6SLePKEsbxd3 oBEth7H0cVppbzgPgnDWyxpx6DXlreKehGFQwuEa7T1NUyzpku5fR5rEgUrhG0w8SEAJ hJzXlbvTkcI/n6fsk1q+0TlP4qzIlw2CA9qmI3SEq/Voc+ncdHGPf8H1eeCCOPZ0PjVA gHh2ykVvcYHDKHqd+RWIXcqnRpgzgc87qXSei6GadZ1TVMDNKMLTgjXt2fwJM+vyeyQi 3Rn0boE7bagJwwaTfxE5mfBhsxsHwo8MADUVgqq3MfNxr/ETE65ewWnRVFYzfVoBCoBq liYg== 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-system-of-record:x-gm-message-state; bh=k98xqsw3P8D0qyqKkOjZP6DYUcNrktN3ZIdlIHtKMSw=; b=R6prS5dp/dLEquLBhiCEsGVcrM6y0UIYcHFAeSv4zzdsCwjHNh835dLhZZ0ZMchnHH wSvv1LoCPLdTrZyxPeX989PgGjkNcJ7H8uA7TH2cDJ1lDOx9xb5r0NoEB3YiE6F5eAtQ LbDJip0nULr8Ei4p9B8HugoP4Fyk18uqNfjUAvSqHovggkVISTusmoEDRS7qNE6IpPKD Ta9H211rNQ2y4BrchKSBuw8ghUELtUjVrRYSV7y2uoi9yWO02BOcPS5yirBNH4/A4eo/ 2M4geqHwT7bzbPs4MNYIuB8/mr+QyeODKYo93qppsLgKu1YU/qxnF/6RlbM+utg61rcN FReA== Received: by 10.50.106.234 with SMTP id gx10mr11245123igb.36.1350368853175; Mon, 15 Oct 2012 23:27:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Mon, 15 Oct 2012 23:27:11 -0700 (PDT) In-Reply-To: <20121016061958.24942.45385.idtracker@ietfa.amsl.com> References: <20121016061958.24942.45385.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Tue, 16 Oct 2012 15:27:11 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f235447cf2d0704cc273f94 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnpZtXIYUOxEqGLIAB7Dvl1I/bQUdkwQu2IdSbcX/720qAOxH81y/I0sYfTGXHyP1zOilq7Fts2sKiNoSVketH1onRvW6o3zhaZpk+HmoZV5VExhz9hRapzBqxztlw3x7bLFHfhjFGaxWidyrkJOZ3AdtP1l0+8Mt2q9TjnclhssJdBHiLE1Dp4McOXcmqiLAkG9r01 Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-03.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, 16 Oct 2012 06:27:35 -0000 --e89a8f235447cf2d0704cc273f94 Content-Type: text/plain; charset=ISO-8859-1 Changes - without c2s_max_window_size from client, server cannot send c2s_max_window_size - server must ignore invalid/unknown/unacceptable method description - endpoints SHOULD support no context takeover parameters - endpoints MAY support max window size parameters based on discussion on these threads http://www.ietf.org/mail-archive/web/hybi/current/msg09860.html http://www.ietf.org/mail-archive/web/hybi/current/msg09871.html Thanks On Tue, Oct 16, 2012 at 3:19 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 : WebSocket Per-message Compression > Author(s) : Takeshi Yoshino > Filename : draft-ietf-hybi-permessage-compression-03.txt > Pages : 20 > Date : 2012-10-15 > > Abstract: > This specification defines a WebSocket extension that adds > compression functionality to the WebSocket Protocol. It compresses > the payload of non-control WebSocket messages using specified > compression algorithm. One reserved bit RSV1 in the WebSocket frame > header is allocated to control application of compression for each > message. This specification provides one compression method > available for the extension using DEFLATE. > > 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-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-permessage-compression-03 > > > 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 > --e89a8f235447cf2d0704cc273f94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Changes
- without c2s_max_window_size from client, server ca= nnot send c2s_max_window_size
- server must ignore invalid/unknown/una= cceptable method description
- endpoints SHOULD support no context take= over parameters
- endpoints MAY support max window size parameters

based on discussion on these threads

Thanks

On Tue, Oct 16, 2012 at 3:19 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 : WebSocket Per-message Compressi= on
=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-03.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-15

Abstract:
=A0 =A0This specification defines a WebSocket extension that adds
=A0 =A0compression functionality to the WebSocket Protocol. =A0It compresse= s
=A0 =A0the payload of non-control WebSocket messages using specified
=A0 =A0compression algorithm. =A0One reserved bit RSV1 in the WebSocket fra= me
=A0 =A0header is allocated to control application of compression for each =A0 =A0message. =A0This specification provides one compression method
=A0 =A0available for the extension using DEFLATE.

=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-03

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


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

--e89a8f235447cf2d0704cc273f94-- From jamie@shareable.org Tue Oct 16 04:46:56 2012 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 5E23221F87EF for ; Tue, 16 Oct 2012 04:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np6nqVEnMeYZ for ; Tue, 16 Oct 2012 04:46:55 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id AE35C21F86E2 for ; Tue, 16 Oct 2012 04:46:55 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1TO5bn-0004Yd-TL; Tue, 16 Oct 2012 12:46:51 +0100 Date: Tue, 16 Oct 2012 12:46:51 +0100 From: Jamie Lokier To: Simone Bordet Message-ID: <20121016114651.GA30253@jl-vm1.vm.bytemark.co.uk> References: <001501cdaac6$52192ac0$f64b8040$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter 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, 16 Oct 2012 11:46:56 -0000 Simone Bordet wrote: > I'm guessing that if the device can run a browser, then a 32k window is ok. > Is there evidence from mobile browser vendors that this is not the case ? At the small end: I'm increasingly seeing WebSocket be used as a de facto "simple message" replacement for TCP in some small embedded environments, that don't even have enough memory to run a Linux kernel, let alone a browser. http://www.google.com/q=mbed+websocket http://www.google.com/q=arduino+websocket http://www.google.com/q=embedded+websocket Probably because it puts Javascript and C, and browser and bare-metal environment, on an equal footing with the same servers; and because it's standardised. I have no idea if the 32k window is an issue, when those things have a few WebSocket connewctions per client going on. Just pointing out, it is used on small devices not just browsers. On the large end: There is some value in limiting the memory use of mostly-idle and active WebSockets on the server, along with TCP tuning (mainly window size and queuing limits), in order to boost the number of connections per server, to e.g. the order of 1 million connections per server. Unlike with HTTP it's not always acceptable to drop/churn connections under load, and the payloads can be very small. Again I have no idea if the compression extension's 32k window is an issue for this. However, it's larger than TCP memory and other connection state when those are tuned for size (except TLS which is a reason to use something else in this situation) -- Jamie From SRS0+330dee4e0d0b5ecc=IN=noemax.com=arman@noemax.com Tue Oct 16 06:11:07 2012 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 BD1EC21F88A7 for ; Tue, 16 Oct 2012 06:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, GB_AFFORDABLE=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNpBTAXR-ip3 for ; Tue, 16 Oct 2012 06:11:02 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB1221F8709 for ; Tue, 16 Oct 2012 06:11:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1350393064; x=1350997864; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=sF5gg6mxKrReRj6vPR9C+on221g=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=hya02Rvv09PxQqd/qMIAmZ59lEmASzQNqKKqKfHEN8iaLrQdeSJCbIGJxnSQM9sWs3MMlr7YkXIIemKDFPIYPOnpt2aCNii6EMkeZLEJApYl12ayhGu0DdV5JOA89yjrPl6ylEPJDkqLyMeTEyE03JZaaame4UtWWpz3bWNxqLc= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.3) with ASMTP (SSL) id AXB26503; Tue, 16 Oct 2012 16:11:03 +0300 From: "Arman Djusupov" To: "'Jamie Lokier'" , "'Simone Bordet'" References: <001501cdaac6$52192ac0$f64b8040$@noemax.com> <20121016114651.GA30253@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20121016114651.GA30253@jl-vm1.vm.bytemark.co.uk> Date: Tue, 16 Oct 2012 16:10:55 +0300 Message-ID: <00fe01cdab9f$b008d110$101a7330$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQGrGEObTRLSBGYgP6AO/33GaQznVwG/kNc9AWLwMUcC+2NsfZfQHsSQ Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter 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, 16 Oct 2012 13:18:43 -0000 I would like to note that real memory requirements are larger than just the window size, which is only one consideration. Except of the window size, ZLib also allocates a considerable amount of additional memory for various tables, such as the table of hashes which does not depend on the wsize setting but on the number of hash_bits. In the default configuration the latter has a size of about 128KB. If we add the size of the output buffer + some other small tables required by ZStream we can easily climb to 200KB for compression + some amount of memory required for decompression. So the total cost per connection would be around 260 KB, while Takeshi's proposed negotiation would allow us to save +/- 32KB. The amount of memory used by the hashes can be lowered by reducing the hash bits. However I doubt that any implementation would go that far in trying to reduce the amount of memory used, plus doing so can result in very poor compression ratios for the same processing time taken. So if the server is to handle a million connections I'm not sure that DEFLATE would be more affordable than TLS. With best regards, Arman -----Original Message----- From: Jamie Lokier [mailto:jamie@shareable.org] Sent: Tuesday, October 16, 2012 2:47 PM To: Simone Bordet Cc: Arman Djusupov; hybi@ietf.org Subject: Re: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter Simone Bordet wrote: > I'm guessing that if the device can run a browser, then a 32k window is ok. > Is there evidence from mobile browser vendors that this is not the case ? At the small end: I'm increasingly seeing WebSocket be used as a de facto "simple message" replacement for TCP in some small embedded environments, that don't even have enough memory to run a Linux kernel, let alone a browser. http://www.google.com/q=mbed+websocket http://www.google.com/q=arduino+websocket http://www.google.com/q=embedded+websocket Probably because it puts Javascript and C, and browser and bare-metal environment, on an equal footing with the same servers; and because it's standardised. I have no idea if the 32k window is an issue, when those things have a few WebSocket connewctions per client going on. Just pointing out, it is used on small devices not just browsers. On the large end: There is some value in limiting the memory use of mostly-idle and active WebSockets on the server, along with TCP tuning (mainly window size and queuing limits), in order to boost the number of connections per server, to e.g. the order of 1 million connections per server. Unlike with HTTP it's not always acceptable to drop/churn connections under load, and the payloads can be very small. Again I have no idea if the compression extension's 32k window is an issue for this. However, it's larger than TCP memory and other connection state when those are tuned for size (except TLS which is a reason to use something else in this situation) -- Jamie From tobias.oberstein@tavendo.de Thu Oct 18 02:08:28 2012 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 762FE21F85DA for ; Thu, 18 Oct 2012 02:08:28 -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_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLOMdq7XqhQs for ; Thu, 18 Oct 2012 02:08:26 -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 8240621F85EF for ; Thu, 18 Oct 2012 02:08:25 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.219]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Thu, 18 Oct 2012 02:08:25 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Thu, 18 Oct 2012 02:08:26 -0700 Thread-Topic: Update: WebSocket test suite reports Thread-Index: Ac2tD3cpAnKz+exsTWCb0GnEWlKbfA== Message-ID: <634914A010D0B943A035D226786325D433913C607A@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 Cc: "autobahnws@googlegroups.com" Subject: [hybi] Update: WebSocket test suite reports 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, 18 Oct 2012 09:08:28 -0000 Hello, we have updated reports for WebSocket protocol tests for browsers (Chrome, = Firefox, IE10): http://autobahn.ws/testsuite/reports/clients/index.html The results are quite encouraging: all green;) Mobile and server reports will follow up. Cheers, Tobias Couple of notes: 1. The "fail" of IE10 for Case 2.10 is actually testsuite fault (the spec d= oes not require respnding to each and every ping). 2. As can be seen from the 6.4.* Cases, IE10 does fail fast on invalid UTF-= 8 _per frame_. Firefox and Chrome only fail per-message (no fail fast). Aut= obahn does fail-fast even within frames, on the very first offending octet. 3. As can be seen from Cases 9.1.*/9.2.*, Chrome Canary has improved it's l= arge payload processing efficiency a lot compared to current released Chrom= e. 4. The "non-strict" case outcomes for Firefox are due to it's asynchronous = processing of WebSocket. That's perfectly fine. The spec does not require t= o process strictly everything before a break of the protocol. All other cli= ents however seem to do that. 5. The handling of close codes is somewhat inconsistent/different between c= lients. 6. As can be seen from comparing the columns AutobahnClient and AutobahnCli= ent/PyPy, running PyPy vastly improves Autobahn's performance for large pay= loads. The main bottlenecks improved are masking, UTF-8 validation and gene= ral bit banging/shuffling. Caveat: the AutobahnClient/PyPy was running locally next to Autobahn Testsu= ite, different from all the other clients. 7. Safari is not included, since Apple seems to have stopped shipping Safar= i for Windows (and stopped delivering updates for my old Macbook). Test setup: Machine 1: - Core i7, 3.4 Ghz, 12GB Ram - Win8 Rel. Prev. 64 Bit - Browsers and Autobahn on CPython Machine 2: - Core i7, 3.4 Ghz, 12GB Ram - VirtualBox VM running Ubuntu 10.04 LTS on Win7 64-Bit host - Autobahn Testsuite running on PyPy (current trunk compiled from source) - Autobahn Client PyPy Network: 1GbE fully switched From webmaster@zaphoyd.com Thu Oct 18 11:07:47 2012 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 4D65E21F84C6 for ; Thu, 18 Oct 2012 11:07:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRS-aT8vf8ZC for ; Thu, 18 Oct 2012 11:07:46 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 73DC121F84BB for ; Thu, 18 Oct 2012 11:07:46 -0700 (PDT) Received: from c-68-51-76-178.hsd1.il.comcast.net ([68.51.76.178]:39228 helo=[10.0.1.207]) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TOuVU-0005DL-M4; Thu, 18 Oct 2012 14:07:44 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Peter Thorson In-Reply-To: <634914A010D0B943A035D226786325D433913C607A@EXVMBX020-12.exch020.serverdata.net> Date: Thu, 18 Oct 2012 13:07:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <16BC247D-2D4B-4902-A11F-2D923EE2538C@zaphoyd.com> References: <634914A010D0B943A035D226786325D433913C607A@EXVMBX020-12.exch020.serverdata.net> To: Tobias Oberstein X-Mailer: Apple Mail (2.1499) 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-Source: X-Source-Args: X-Source-Dir: Cc: "hybi@ietf.org" , "autobahnws@googlegroups.com" Subject: Re: [hybi] Update: WebSocket test suite reports 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, 18 Oct 2012 18:07:47 -0000 For those curious about Safari 6, it behaves identically to Chrome 22 on = Autobahn tests. (Hurray!) Raw results: (test suite run on cpython so 9.x performance tests may not = be super accurate) http://zaphoyd.com/websocketpp/autobahn-report-client/ On Oct 18, 2012, at 04:08 , Tobias Oberstein = wrote: > Hello, >=20 > we have updated reports for WebSocket protocol tests for browsers = (Chrome, Firefox, IE10): >=20 > http://autobahn.ws/testsuite/reports/clients/index.html >=20 > The results are quite encouraging: all green;) >=20 > Mobile and server reports will follow up. >=20 > Cheers, > Tobias >=20 >=20 > Couple of notes: >=20 > 1. The "fail" of IE10 for Case 2.10 is actually testsuite fault (the = spec does not require respnding to each and every ping). >=20 > 2. As can be seen from the 6.4.* Cases, IE10 does fail fast on invalid = UTF-8 _per frame_. Firefox and Chrome only fail per-message (no fail = fast). Autobahn does fail-fast even within frames, on the very first = offending octet. >=20 > 3. As can be seen from Cases 9.1.*/9.2.*, Chrome Canary has improved = it's large payload processing efficiency a lot compared to current = released Chrome. >=20 > 4. The "non-strict" case outcomes for Firefox are due to it's = asynchronous processing of WebSocket. That's perfectly fine. The spec = does not require to process strictly everything before a break of the = protocol. All other clients however seem to do that. >=20 > 5. The handling of close codes is somewhat inconsistent/different = between clients. >=20 > 6. As can be seen from comparing the columns AutobahnClient and = AutobahnClient/PyPy, running PyPy vastly improves Autobahn's performance = for large payloads. The main bottlenecks improved are masking, UTF-8 = validation and general bit banging/shuffling. >=20 > Caveat: the AutobahnClient/PyPy was running locally next to Autobahn = Testsuite, different from all the other clients. >=20 > 7. Safari is not included, since Apple seems to have stopped shipping = Safari for Windows (and stopped delivering updates for my old Macbook). >=20 >=20 > Test setup: >=20 > Machine 1: > - Core i7, 3.4 Ghz, 12GB Ram > - Win8 Rel. Prev. 64 Bit > - Browsers and Autobahn on CPython >=20 > Machine 2: > - Core i7, 3.4 Ghz, 12GB Ram > - VirtualBox VM running Ubuntu 10.04 LTS on Win7 64-Bit host > - Autobahn Testsuite running on PyPy (current trunk compiled from = source) > - Autobahn Client PyPy >=20 > Network: 1GbE fully switched > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From internet-drafts@ietf.org Fri Oct 19 02:40:30 2012 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 30A0B21F849E; Fri, 19 Oct 2012 02:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQDRAYO7zvcr; Fri, 19 Oct 2012 02:40:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E3521F8487; Fri, 19 Oct 2012 02:40:29 -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.34 Message-ID: <20121019094029.20722.68368.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 02:40:29 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-04.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: Fri, 19 Oct 2012 09:40:30 -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 : WebSocket Per-message Compression Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-permessage-compression-04.txt Pages : 21 Date : 2012-10-19 Abstract: This specification defines a WebSocket extension that adds compression functionality to the WebSocket Protocol. It compresses the payload of non-control WebSocket messages using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each message. This specification provides one compression method available for the extension using DEFLATE. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-permessage-compression-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Fri Oct 19 02:44:43 2012 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 6627721F8532 for ; Fri, 19 Oct 2012 02:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.851 X-Spam-Level: X-Spam-Status: No, score=-102.851 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UraOxbPVnKWe for ; Fri, 19 Oct 2012 02:44:42 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26D4B21F8436 for ; Fri, 19 Oct 2012 02:44:41 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so210258lam.31 for ; Fri, 19 Oct 2012 02:44:41 -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:x-system-of-record; bh=k3yikx2QKlRsj7iG0Crif0xXoQEeKy9Ys26guzdnVBo=; b=f5UnQN8WQFyNvidJZm7kDaSkxsuk9cd7eylFzEIKN7paTPS7cLC/fActM2BOM4qByB 3ktIleVj/lJ6UNbU8hqP/g7ZbwkgM54/yMIgPMWbfAXd8RGRxnIozG7bHVgS93XmXKtc qB+Ih9/Zc2CA0hHMhBA13Gcs0MamNCkZnwdvlhUJbxB2+Ti1r55FhYsG9DTD+VXH0JoA uIFcGHnoL6qSrHRcIs/dW/0jCdNBQ+JKZHm8W53GU34UrYF0lVNN08EaI4+8ckl0FzFj hssgpBsdBeBtx8vGNAq9FbSdl5bID5DSywmOHaiGVtHZFdbxlpnWq6w2IVoh5G/z2e35 rpzA== 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-system-of-record:x-gm-message-state; bh=k3yikx2QKlRsj7iG0Crif0xXoQEeKy9Ys26guzdnVBo=; b=mwc/8NCe7qx+7pv+LJbKfLD1ZZTys4gFuhySnfrLjkvYlgCVyTyiAXpCzUR4Z1Orjm Qax9Bawhyn2tcRB7QDRlOtshMLHz4TDmw8xxTH1l2D9uz2gvYVBQkqTyphnuHsmIMZqz rR1PWB9KaBXCcsnkGghufim9WTiGF064lQ+KXJRpARE0rnAriJKlWSoTAMDTarYbsiPd mtH8eU1Vz0dJKSXZd1GB8hnMbVCzV4Hv8MQNeW2141Yu8NaJkL3WEVWMvDCyP+G9eoyI SY5LxK2rL5Jp/IqJTx9a8YPacrAXBTPiIhIxHa94XTISQIyFX/15ccsReUHRSpyFUmze 2s8Q== Received: by 10.152.105.103 with SMTP id gl7mr671302lab.10.1350639881080; Fri, 19 Oct 2012 02:44:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.44.131 with HTTP; Fri, 19 Oct 2012 02:44:20 -0700 (PDT) In-Reply-To: <20121019094029.20722.68368.idtracker@ietfa.amsl.com> References: <20121019094029.20722.68368.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Fri, 19 Oct 2012 18:44:20 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=f46d040714a754cf1404cc665ae8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn1zMiuvBqjWZcq/RjQYxVyFnAUVPaGB4OlFH9nJlbSM0W6eYDrHGmfmgaSayMfYGgWe6O07fe22uiZrhp/8oUjeAewzA5l9tile8+Ya6URx3w3c3kM4Nx2GT+vUSK8IhSEgmdHs2LTjY3dINVDyUAY6lQZ0x1zNGAltR/Mh4o39EHOVPM5dZZHW0rYP9p0f/BJTYKW Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-04.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: Fri, 19 Oct 2012 09:44:43 -0000 --f46d040714a754cf1404cc665ae8 Content-Type: text/plain; charset=ISO-8859-1 Changes - added examples of the deflate method parameters - added ABNF for the window size parameters' value Thanks On Fri, Oct 19, 2012 at 6:40 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 : WebSocket Per-message Compression > Author(s) : Takeshi Yoshino > Filename : draft-ietf-hybi-permessage-compression-04.txt > Pages : 21 > Date : 2012-10-19 > > Abstract: > This specification defines a WebSocket extension that adds > compression functionality to the WebSocket Protocol. It compresses > the payload of non-control WebSocket messages using specified > compression algorithm. One reserved bit RSV1 in the WebSocket frame > header is allocated to control application of compression for each > message. This specification provides one compression method > available for the extension using DEFLATE. > > 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-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-permessage-compression-04 > > > 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 > --f46d040714a754cf1404cc665ae8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Changes
- added examples of the deflate method parameters
- a= dded ABNF for the window size parameters' value

Thanks

On Fri, Oct 19, 2012 at 6= :40 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 : WebSocket Per-message Compressi= on
=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-04.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-19

Abstract:
=A0 =A0This specification defines a WebSocket extension that adds
=A0 =A0compression functionality to the WebSocket Protocol. =A0It compresse= s
=A0 =A0the payload of non-control WebSocket messages using specified
=A0 =A0compression algorithm. =A0One reserved bit RSV1 in the WebSocket fra= me
=A0 =A0header is allocated to control application of compression for each =A0 =A0message. =A0This specification provides one compression method
=A0 =A0available for the extension using DEFLATE.

=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-04

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


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

--f46d040714a754cf1404cc665ae8-- From block.rxckin.beats@gmail.com Sat Oct 20 01:47:36 2012 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 7E2B021F85E7 for ; Sat, 20 Oct 2012 01:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EYCUCbkpsbx for ; Sat, 20 Oct 2012 01:47:36 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E262021F85C1 for ; Sat, 20 Oct 2012 01:47:35 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1387381oag.31 for ; Sat, 20 Oct 2012 01:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=f/Yqox36tWTfW4iCBx/WYAIT92LD89R2lAjXSk/Ktuo=; b=wJ4bBtvXr4qOE/SqXfdsIkMhHgWXS1PnjxcsS1fvqW7d+IE5eOjXQ+09cQ2HfsWkKI +uI5fJjatc1qIjESA4CSAEmtUNQk27AfM/sRnPQrXC+CAdgJHVZ6wXWb1IxZb/W+euW/ WHIOl+FNBeBQBI8Ec145dC2HP2o22YnsNbOqFsQAoDgHpuZsi6WMH44osFdwyZm1eGeT kOInDKQSMM2WOUvEVSKcmp8lai3zz6Z1O00iCKH0r0+BZ94ajWpM7pPqL8faGlTLEGDr 0B3hOtSfeI64QkilVOXw5CS8lmIncXuEawFH/3Q9V29dQsozZy3yksfIEiLV08xOVczr CCzA== Received: by 10.60.5.138 with SMTP id s10mr3458643oes.80.1350722855474; Sat, 20 Oct 2012 01:47:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.73.228 with HTTP; Sat, 20 Oct 2012 01:47:15 -0700 (PDT) From: yusuke Date: Sat, 20 Oct 2012 17:47:15 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff252cefd95e904cc79ab20 Subject: [hybi] very small typo 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, 20 Oct 2012 08:47:36 -0000 --e89a8ff252cefd95e904cc79ab20 Content-Type: text/plain; charset=ISO-8859-1 I found small typo. mux-08 1, overview - taged + tagged 1.1 Physical Connection and Logical Channels - "mutiplexed connections" +"multiplexed connections" thanks. --e89a8ff252cefd95e904cc79ab20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I found small typo.

mux-08
=A0 1, overview
=A0 =A0 =A0- tag= ed
=A0 =A0 =A0+ tagged


=A0 1.1 Physical Connection= and Logical Channels
=A0 =A0 =A0- "mutiplexed connections"
=A0 =A0 =A0+"multiplexed connections"


thanks.
--e89a8ff252cefd95e904cc79ab20-- From tyoshino@google.com Sun Oct 21 22:47:49 2012 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 7D9F021F8B37 for ; Sun, 21 Oct 2012 22:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.855 X-Spam-Level: X-Spam-Status: No, score=-102.855 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y21T4ReQ8ipS for ; Sun, 21 Oct 2012 22:47:49 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0376621F8870 for ; Sun, 21 Oct 2012 22:47:48 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3676738iec.31 for ; Sun, 21 Oct 2012 22:47:48 -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:x-system-of-record; bh=wzwr980WhTOZfWjDh1zKyUv8HrH90kjjLKjNUSPYyeA=; b=ZSwUp2YY5Tys6pCnIOHgTU8mYLjplv4qgn7vKiyzeokLqmSuzXjMv6huHUO1kFRnob UoEDY340mfP0bn1Ek1DVe0pbMrACamoIuE/zNIP7s6ytV9OHIjujok6Hfwp+zLzRIidF 0uBVOLqPGLn/11iRcBN0jqF5vlxnm4t7au1LEl04rS/0hJQOZxYeIQCG7btV/PVahneh 3B8JinNtcnpl+hkaerp+AKKvtTZfexbYAA6uIUF2hJgAdH9Z9niEIBe5B3MIFJzXtBsN Mj2NQHADohLG2Z03YRsiUPFPYCLCjZEDJD0L+h3DeLoa22HImwlnczQ6iNdKJsRMbG8A 9uhw== 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-system-of-record:x-gm-message-state; bh=wzwr980WhTOZfWjDh1zKyUv8HrH90kjjLKjNUSPYyeA=; b=Xeh1W7HRsGTItfO00j/0WdG57wvMJmVW9TABaCdVSVzlYyq0IuQfaSv1whbglR7LrE z9RrzaMvr4aI9pQbZWpUv6dCZ8c6e//EJUjOgxP8S2Pq7oYTSbiijMF+hsbLOvAKDQEb o320yxEkkImdhmD0wZRvc2ogKPm9PtTrvlK62Mk7HvU5+e2+r2lHZ8tetwpLfRGcG63J 1mJuI12NyYdO2oaHuTlhBgboICEvPK5wrJzt3jSzBvVz6BpveMIo/pDx6VsJ0MgVkhr7 BTGgUkIDMqTCRkI0PVU42G6NFrxO96wzMvpGAf8HtnBAAKLtzxcK9Dbhel4IN8Rrmflf GjDA== Received: by 10.50.46.134 with SMTP id v6mr8124185igm.55.1350884868480; Sun, 21 Oct 2012 22:47:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.180.98 with HTTP; Sun, 21 Oct 2012 22:47:28 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Mon, 22 Oct 2012 14:47:28 +0900 Message-ID: To: yusuke Content-Type: multipart/alternative; boundary=14dae9340f53b7dd3a04cc9f64c0 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl4bPC960BW1ZpNOCkVc8HTaNtdd2Vt65rfOTD8XoiYiGn+W2H+45wdxjMGOMv/eaYeD72MbOvavALvECNnZvOAmisbi/yx8fZfULduXXyoG2pU/VwVRGamHyxQRztJ1kOx30QFx72ImLlssxqS7+OCUVO9mE2xquixvkieHZ5rF3ZY251CyAbiHaqs/U/KjcHQPUDw Cc: hybi@ietf.org Subject: Re: [hybi] very small typo 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, 22 Oct 2012 05:47:49 -0000 --14dae9340f53b7dd3a04cc9f64c0 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the report. I'll address them in the next version. On Sat, Oct 20, 2012 at 5:47 PM, yusuke wrote: > I found small typo. > > mux-08 > 1, overview > - taged > + tagged > > > 1.1 Physical Connection and Logical Channels > - "mutiplexed connections" > +"multiplexed connections" > > --14dae9340f53b7dd3a04cc9f64c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the report. I'll address them in the next version.
On Sat, Oct 20, 2012 at 5:47 PM, yusuke <block.rxckin.beats@gmail.com> wrote:
I found small typo.

mux-08
=A0 1, overview
=A0 =A0 =A0- taged
=A0 =A0 =A0+ tagged


=A0 1.1 Physical Connection and Logical Channels
=A0 =A0 =A0- "mutiplexed connections"
=A0 =A0 =A0+"= multiplexed connections"

--14dae9340f53b7dd3a04cc9f64c0-- From salvatore.loreto@ericsson.com Tue Oct 23 04:59:43 2012 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 D10D221F86CA for ; Tue, 23 Oct 2012 04:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.374 X-Spam-Level: X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MatAMNhr11ZP for ; Tue, 23 Oct 2012 04:59:43 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BDFEE21F86BC for ; Tue, 23 Oct 2012 04:59:42 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-c4-508686adf410 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0C.B6.11467.DA686805; Tue, 23 Oct 2012 13:59:41 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 23 Oct 2012 13:59:40 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8B5B22383; Tue, 23 Oct 2012 14:59:40 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D82BA5392D; Tue, 23 Oct 2012 14:59:39 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7BC675309C; Tue, 23 Oct 2012 14:59:39 +0300 (EEST) Message-ID: <508686AB.4000409@ericsson.com> Date: Tue, 23 Oct 2012 14:59:39 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvre7atrYAg2fbBSwOLb7EanF85kZm i/cvtzFZbHt1mNWBxaNlVS+zx4JNpR5Llvxk8mjd8Zc9gCWKyyYlNSezLLVI3y6BK2P/ppVM BYtYK+5+Os/UwLiEpYuRk0NCwETi78STbBC2mMSFe+uBbC4OIYFTjBIb72xhhnA2MEocerIQ rEpIYDejxN/jjBD2OkaJ0zODIIqWAXXsOMMKkuAV0JZo6l8M1sAioCqxfcJNsHVsAmYSzx+C TOXkEBVIlpi34SozRL2gxMmZT8BqRASUJbq+nGABGcos0MMocaKhmR0kISyQKrFzVSdYEbOA rcSFOdehbHmJ7W/nMEP8oCZx9dwmZojrtCR6z3YyTWAUnoVkxywk7bOQtC9gZF7FKJybmJmT Xm6ol1qUmVxcnJ+nV5y6iREYBwe3/NbdwXjqnMghRmkOFiVxXq6k/f5CAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGOtz/76a0fvwn1LI/q2H1mxomfJ4adTyaOHYc5wS4esvVjLFFX1QTNfJ UYm4bfGVkflwE9uXRjNr3tl6F2cd1Zykfqo29ZiPnyn/FM2mBS/uRS5dqLXR/IvF0SDH5Reu v96/zN9Z/eidzWWOVsufdkzZIs77j4ur5LL3L5X3i79M1tW6lSBtd1eJpTgj0VCLuag4EQB9 dNYxUQIAAA== Cc: Gabriel Montenegro , Barry Leiba Subject: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th) 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, 23 Oct 2012 11:59:43 -0000 Hi there, this message initiates a three-weeks working group last call (WG LC) on draft-ietf-hybi-permessage-compression-04 to be completed on November 14th: http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-04 At this point, we haven't seen any objection on the core design of this extension for quite long, all the feedback/clarification-requests raised in the mailing list have been addressed by the Takeshi. Note: to clarify to those not so familiar with the IETF process, a WG LC is a final check within the working group to prepare a draft to be ready for subsequent submission to the IESG Thanks, Gabriel and Salvatore From tyoshino@google.com Tue Oct 23 23:34:11 2012 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 4BAE921F85A2 for ; Tue, 23 Oct 2012 23:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.989 X-Spam-Level: X-Spam-Status: No, score=-102.989 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSgi7eD9zk1N for ; Tue, 23 Oct 2012 23:34:10 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A74921F8586 for ; Tue, 23 Oct 2012 23:34:10 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so108595lam.31 for ; Tue, 23 Oct 2012 23:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=ps0NU+qso1Wz8YdUf1QrM9Q7o/43Rf7Fa5vOvqDR2iE=; b=Sc8Qx1bektallg1CnbS8u3aItbIMfsiSGSSrlLonvUVzpH4YpqFGRH92qtCiOl9/MO 0X1I7H5MkR1WEh3v351zygD7zCj75NhIdJwX0PaN4zHNhxocXqa/xBbGEMykRSaNdml+ e8XcYdvSJeM8yvg+dKNpMXh5WUw6pkHF0XKzcQnoTlDwUU4dsruD1sRTPCHPJxcmhRO+ vdfSzSoGr2spvXqwSFquPL4xJU91x/4iTggIij0Wqf3tDuvAaVeV1an/EB/mLYMZjSVs fn3HVaN9Lo8LFTyjSpZAcTnwG1vpgF5lBNaG8JI0HoPyfhNZ+sfYo+I1fKD9BuQwLJUJ PytQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=ps0NU+qso1Wz8YdUf1QrM9Q7o/43Rf7Fa5vOvqDR2iE=; b=SELDtWkIqzVHvOjp/F80QijDk4NUZPgV1eGwkoW/X0qmCNuRDgr/zwrarJzpzz8aIw 1uxMpbizQyiDx10NiqEJbwPq8GrcPBZ3Fho1y30yFOM1pYcSslGQ4ZfFmYLOVnJ4fCs3 dKV+vqpkjTHEWFF/j8FJpIGNPKoKRcj6/c62prQPVnzXFhsGHfWDiGBwBFfjpMKavqKJ gGTUTYsKogJDxSkThi0AnWHKEMIFrbYyWRDdlQboTV+955j2HMfpOEThH4x9X/XJAjDX e/4hrjIwGb3X/R3dY/hj2RydEJkcvXFS0YEovomhbi1IH8J//KfNpNd1Ik7/w3AWpAol 471A== Received: by 10.112.85.6 with SMTP id d6mr5823390lbz.127.1351060449288; Tue, 23 Oct 2012 23:34:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.19.103 with HTTP; Tue, 23 Oct 2012 23:33:49 -0700 (PDT) From: Takeshi Yoshino Date: Wed, 24 Oct 2012 15:33:49 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=bcaec555548226619904ccc84614 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnStana5aTVNBGNQSJbJVxi08p+WZM/YUVC8MI14ieqzE3XdLF8n0QD6MxyfPVQQVhFF1kb6BZldx63Wly4X9mQ28JofqOcLwAnuWxGu7ijGAiu2lnRNcE0LRLTP3LE0EcNgrIrVcxUmBTxvVjHqC8zJaeF6ebbqUyb34SHVBIleLsvCGvCSA1pXVn3hDaZA9585JyY Subject: [hybi] Multiplexing upcoming change for -09 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, 24 Oct 2012 06:34:11 -0000 --bcaec555548226619904ccc84614 Content-Type: text/plain; charset=ISO-8859-1 FYI, in the next version of the multiplexing spec, I'll - clarify that when control messages are fragmented by the multiplexing extension, continuation type (%x0) is used -- with a note stating that it's not ambiguous for the demultiplexor since control messages are not fragmented on the original connection - address typo report http://www.ietf.org/mail-archive/web/hybi/current/msg09825.html I-D submission is closed until the end of the Atlanta f2f meeting. --bcaec555548226619904ccc84614 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI, in the next version of the multiplexing spec, I'll
= - clarify that when control messages are fragmented by the multiplexing ext= ension, continuation type (%x0) is used
-- with a note stating th= at it's not ambiguous for the demultiplexor since control messages are = not fragmented on the original connection
- address typo report http://www.ietf.org/mail-archive/web/hybi/current/ms= g09825.html

I-D submission is closed until the end of the Atlanta f= 2f meeting.

--bcaec555548226619904ccc84614-- From salvatore.loreto@ericsson.com Wed Oct 24 02:50:08 2012 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 A1F3821F8A49 for ; Wed, 24 Oct 2012 02:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.359 X-Spam-Level: X-Spam-Status: No, score=-106.359 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpIuDwpsTvdv for ; Wed, 24 Oct 2012 02:50:07 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D204521F8A2D for ; Wed, 24 Oct 2012 02:50:06 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-7f-5087b9ccb179 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C6.42.17130.CC9B7805; Wed, 24 Oct 2012 11:50:04 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Oct 2012 11:50:04 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D8DC2244F for ; Wed, 24 Oct 2012 12:50:03 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6724F53A5C for ; Wed, 24 Oct 2012 12:50:03 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1E4A153988 for ; Wed, 24 Oct 2012 12:50:03 +0300 (EEST) Message-ID: <5087B9CB.2080604@ericsson.com> Date: Wed, 24 Oct 2012 12:50:03 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090605070302090802020309" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvre6Zne0BBl93qlu8f7mNyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGaufX2MueCJT8fLOeqYGxgeiXYycHBICJhJznj9mg7DFJC7c Ww9kc3EICZxilDjWfJgVwtnAKHH/zyx2COc8o8SVvy3sIC1CAocYJZ5MEoJI7GKUmDFxFStI gldAW+L5jAPMIDaLgKpEy9GTjCA2m4CZxPOHW8DiogLJEvM2XGWGqBeUODnzCQuILQJkd29d AxYXFgiSuPXyPtRN3xglTjQ9BSviFAiUWNP0FKiIg4NZIEzi4pxciB/UJK6e28QMcZyWRO/Z TqYJjMKzkKyYhdABEmYWsJW4MOc6C4QtL7H97RxmCFtX4sL/KSjiCxjZVjEK5yZm5qSXm+ul FmUmFxfn5+kVp25iBMbEwS2/DXYwbrovdohRmoNFSZxXT3W/v5BAemJJanZqakFqUXxRaU5q 8SFGJg5OqQZGxjPVz9eY+DzbuViriLEyhD95aefu/TvnnLx974ad/s0Jk027lG0/bNs/6dYn DlernxUykTIT9pyZv1zAaat0XS9vi/b0So27B7R+drxrUuhw+ed81VY+W0ygNfBj5rnbjQce Fq8KC/9o8HRC2cLm8iNrWk3l66Tfnbv1yYD3HcfV9Xqn22O4lFiKMxINtZiLihMBEMHcNlcC AAA= Subject: Re: [hybi] "Cache-Control: no-cache" may improve handshake success rate 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, 24 Oct 2012 09:50:08 -0000 --------------090605070302090802020309 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 10/13/12 7:44 AM, Takeshi Yoshino wrote: > Hi, > > On Sat, Oct 13, 2012 at 8:10 AM, Gabriel Montenegro > > wrote: > > Thanks, Takeshi, this is potentially low hanging fruit to obtain > some improvement. BTW, is there any number about how much > improvement has been observed or could be expected? > > > Yes. I want statistics, but for now the Chromium bug entry is the only > report we have. > > When we run some live experiment next time, I'll consider adding some > items to check that. Thanks, Takeshi for reporting this to the HyBi mailing list. Maybe at some point if someone has the energy to do it we can start to document all this information and possible ways to obtain some improvements in a draft (i.e. a sort of miscellaneous draft) or even just on the wiki of the HyBi wg br /Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------090605070302090802020309 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 10/13/12 7:44 AM, Takeshi Yoshino wrote:
Hi,

On Sat, Oct 13, 2012 at 8:10 AM, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> wrote:

Thanks, Takeshi, this is potentially low hanging fruit to obtain some improvement.  BTW, is there any number about how much improvement has been observed or could be expected?


Yes. I want statistics, but for now the Chromium bug entry is the only report we have.

When we run some live experiment next time, I'll consider adding some items to check that.
 
Thanks, Takeshi for reporting this to the HyBi mailing list.
Maybe at some point if someone has the energy to do it we can start to document all this information
and possible ways to obtain some improvements in a draft (i.e. a sort of miscellaneous draft)
or even just on the wiki of the HyBi wg

br
/Salvatore
-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------090605070302090802020309-- From joakim@intalio.com Wed Oct 24 15:06:45 2012 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 7964F1F0C69 for ; Wed, 24 Oct 2012 15:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur+-Ha0prNPN for ; Wed, 24 Oct 2012 15:06:44 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD5B41F0C49 for ; Wed, 24 Oct 2012 15:06:44 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so668167pad.31 for ; Wed, 24 Oct 2012 15:06:44 -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 :x-gm-message-state; bh=z2pL2Wjdmg3XyxaKA2QhzU7xmfyQnkuOFUFe2SOFt/I=; b=OjSvguu/30GLOZ7PPY9lbS7mnyC+gqghsTC2q691vJTQ3z/i/pWaPvBchsjXQp6fYL tkBUh5HK3L88DICRg4Wi8T6Nbx1HXa+/GDvYy089y6d0S2HFZsmCkAr5s4IHqk3ZuG8A aKDFehrEV1h4jKDsgAWItW8SbRKVSKXAVnpH9Gnu0W75s6rLymIiGyv/gzizQbLCkToq a9OiF1gjZpDTMpItnzd+j0OL6oL0Lg6obfIvHBignvCidAmis+hp3SszmuNAPZEaRa2l umq1dnDe2T/5wLCtNYCR7Jt8M6iz6924mpuEiOXS+vxqySVAjWm87h8KBPvsbTOORv93 xGNg== MIME-Version: 1.0 Received: by 10.68.235.71 with SMTP id uk7mr54307974pbc.10.1351116404526; Wed, 24 Oct 2012 15:06:44 -0700 (PDT) Received: by 10.66.77.162 with HTTP; Wed, 24 Oct 2012 15:06:44 -0700 (PDT) Date: Wed, 24 Oct 2012 15:06:44 -0700 Message-ID: From: Joakim Erdfelt To: hybi@ietf.org Content-Type: multipart/alternative; boundary=047d7b33d1a6578c7c04ccd54de1 X-Gm-Message-State: ALoCoQkj/ihAseofL2DkcvQQC0GPbwo78IBb2898EQjmNMxFYFtpfFk/IWTB2mX8DsZZ2VG7lOx0 Subject: [hybi] Multiplex examples & continuations 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, 24 Oct 2012 22:06:45 -0000 --047d7b33d1a6578c7c04ccd54de1 Content-Type: text/plain; charset=ISO-8859-1 While parsing the examples at ... https://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-08#section-10 The 2nd example says: 0x02 0x07 0x01 0x81 "Hello" 0x80 0x06 " world" This is a fragmented encapsulating message converying a non- fragmented text frame "Hello world" on logical channel 1. So to translate what I see in this example. 2 WebSocket base frames. Frame 1) WebSocket Frame #1 OpCode: BINARY (2) Fin: False RSV: None set Masking: Not set Payload: (7 bytes) Mux Payload: Channel ID: 1 OpCode: TEXT (1) Fin: True <-- That right? RSV: None set Payload: "Hello" (UTF8 bytes) Frame 2) WebSocket Frame #2 OpCode: CONTINUATION (0) Fin: True RSV: None set Masking: Not set Payload: (6 bytes) (No mux encapsulation) Is this behavior for Continuation frames correct? Assume continuation frames belong to the last encapsulated data frame? Also, is the first frame supposed to have encapsulated Fin=true? Shouldn't that be Fin=false? Thanks again, -- Joakim Erdfelt --047d7b33d1a6578c7c04ccd54de1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
While parsing the examples at ...


The 2nd example says:

0x0= 2 0x07 0x01 0x81 "Hello" 0x80 0x06 " world"
<= br>
=A0 =A0 =A0 This is a fragmented encapsulating message conver= ying a non-
=A0 =A0 =A0 fragmented text frame "Hello world" on logical c= hannel 1.

So to translate what I see in this= example.

2 WebSocket base frames.

<= /div>
Frame 1) WebSocket Frame #1

OpCode: BINARY (2= )
Fin: False
RSV: None set
Masking: Not set
Payload: (7 bytes)
Mux Payload:
=A0 =A0Channel= ID: 1
=A0 =A0OpCode: TEXT (1)
=A0 =A0Fin: True =A0<-- That righ= t?
=A0 =A0RSV: None set
=A0 =A0Payload: "Hello&quo= t; (UTF8 bytes)

Frame 2) WebSocket Frame #2
<= div>
OpCode: CONTINUATION (0)
Fin: True
RSV: None set
Masking: Not set
Payload: (6 bytes)
(No mux en= capsulation)

=A0 =A0
Is this behavior fo= r Continuation frames correct?
Assume continuation frames belong to the last encapsulated data frame?=
Also, is the first frame supposed to have encapsulated Fin=3Dtru= e? =A0Shouldn't that be Fin=3Dfalse?

Thanks again,<= div>
--
Joakim Erdfelt <joakim@intalio.com>

--047d7b33d1a6578c7c04ccd54de1-- From tyoshino@google.com Thu Oct 25 01:40:10 2012 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 2ACF321F8869 for ; Thu, 25 Oct 2012 01:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.989 X-Spam-Level: X-Spam-Status: No, score=-102.989 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiw2A4ggpS1D for ; Thu, 25 Oct 2012 01:40:09 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6621F85F4 for ; Thu, 25 Oct 2012 01:40:08 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so1267565lam.31 for ; Thu, 25 Oct 2012 01:40:08 -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:x-system-of-record; bh=nQdfPSwv4u+kKVTtgk+Bj98SmKIRYShv5ShzVaRxAu4=; b=LYxFrx1yto6VpiohRujYacjQDSM3ONYouTrTMpozVb7/v6LxvlTZE+Z9d6+6/HVUk/ lhaZi8qXO5ZCE/q+yqzj10vLX3/N37oJnhNaptzY237//ldiOlVHvU/Wz4VzDjrnWZ5G cRJpXLZ6PV3LMxcn3CeTA69oDK76eHBkSJT/V4loSDptvZsd6GfXJa6XJkrym8m6xWAu WGdS+b2bRRMlzGOHxRn0LJun9zZ2oHJwHno1jIsFm4RD5YGlu1ebOj7LvTdPHlKkejMU MgQEgTHcBDBe7axg2IAYPNacbziPbaJ4qh5w8QfLxtYJZCa5yAPy8CY4X+GwPA+KbFXb TN+A== 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-system-of-record:x-gm-message-state; bh=nQdfPSwv4u+kKVTtgk+Bj98SmKIRYShv5ShzVaRxAu4=; b=YzApvcMyIzot0RJwsImC5thV+HLpUW8LOQ9TrhBsNT+jyPko/Ta7RBbl+hzUHGWkGi evrjxzSclwfzfVhts9Sgehomdwmiva1B5qDOdXDvY8Nx0gW8nPmzl9huKWxuUzzgnmzI WDaLXDWvJiTEW0jiQ2p4RpBAnIPbyl5th95jpkhif5YiFQPLGcgNW4+BSIQGURzrYjq0 Hq3y2YL10tYEvvzP0MTXf28z9XqTkro2VvLHH9nuQJeeOBjaq11RHaMwJ90R7ukJxuyd vkOpBfe4QQSwfgZyBxeb7fn53N5GsvROQ/erRSY6CHZlYmyikKsP+j55mYupnT2oW8ov yPKA== Received: by 10.112.43.193 with SMTP id y1mr7129422lbl.68.1351154407957; Thu, 25 Oct 2012 01:40:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.10.163 with HTTP; Thu, 25 Oct 2012 01:39:47 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 25 Oct 2012 17:39:47 +0900 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=e0cb4efe2aec85e4d104ccde2607 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnIxx+janaKrSsv+S/P1NTMSqn/z9QxrEt04Au5Q2ilCg2Tv4e+LTaUPhFgVKsns9NaXTc81dVibUp4c2LD5VNynlT9oCjEkRKad98aVyXsewopy9cV/XYeOUHrS9eHp6gPgxXMixEwQ604wLHcB4vYAsiQXq7TPCZZdA0oQwLY6rfqrdg/oDXy9G1EMNpVE++tFSwz Cc: hybi@ietf.org Subject: Re: [hybi] Multiplex examples & continuations 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, 25 Oct 2012 08:40:10 -0000 --e0cb4efe2aec85e4d104ccde2607 Content-Type: text/plain; charset=ISO-8859-1 Current multiplexing spec is message-based. It's no longer based on frame-to-frame encapsulation approach. Each WebSocket "message" carries one original frame. In this example, the message (fragmented into two frames) carries 0x01(channel 1) 0x81(FIN, TEXT) "Hello world" that was originally 0x81 0x11 "Hello world" on the multiplexed connection (channel 1). This allows intermediaries that doesn't understand multiplexing to safely change fragmentation of received data without knowledge of multiplexing. --e0cb4efe2aec85e4d104ccde2607 Content-Type: text/html; charset=ISO-8859-1
Current multiplexing spec is message-based. It's no longer based on frame-to-frame encapsulation approach. Each WebSocket "message" carries one original frame.

In this example, the message (fragmented into two frames) carries 0x01(channel 1) 0x81(FIN, TEXT) "Hello world" that was originally 0x81 0x11 "Hello world" on the multiplexed connection (channel 1).

This allows intermediaries that doesn't understand multiplexing to safely change fragmentation of received data without knowledge of multiplexing.

--e0cb4efe2aec85e4d104ccde2607-- From joakim@intalio.com Thu Oct 25 06:26:57 2012 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 ED9D021F892B for ; Thu, 25 Oct 2012 06:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.856 X-Spam-Level: X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYnNoNtVpVdv for ; Thu, 25 Oct 2012 06:26:57 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 332BE21F879C for ; Thu, 25 Oct 2012 06:26:57 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so787775dan.31 for ; Thu, 25 Oct 2012 06:26:56 -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=wPQSpzIQIFW3Mq+44lnBoHn4fAysNlY+eNO8hb8lWrY=; b=DAthtVFIMbDmvhNJqTHk6GMQL8FTY9ut19BQ+EYET2Gt5SjKTKqGntr0Y4+tc3ZeIg ws4aZVHGu+98hszVJY6i6caQNxhRIvz2o6iVPNi7316GIWZa/cuOz/Q0y+JmydoZxMg/ 8mXHDTJ4B+UbdCBK8kYJ58bmyC8G9QrTqqMdtABFqLYHsjciTo3BgjWZNyITAngkFQzl fXAX17NxWkwFmHUNTnI4/W/B1DquBvOCDDZ4GDMaf4zXHFFm7hcDjBSi8KkZlTktXbX3 flj5HUrRAhL4ZPsJ4leeHIKHZbxX6THVHHdFZkSaW/7Vi8hsARa4in7OM7F3FCeGyJbz thvA== MIME-Version: 1.0 Received: by 10.68.137.228 with SMTP id ql4mr60228492pbb.125.1351171616798; Thu, 25 Oct 2012 06:26:56 -0700 (PDT) Received: by 10.66.77.162 with HTTP; Thu, 25 Oct 2012 06:26:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Oct 2012 06:26:56 -0700 Message-ID: From: Joakim Erdfelt To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=047d7b2e3fa83ff82d04cce2287c X-Gm-Message-State: ALoCoQmCqHyOY0qLC20azPRGb3Ho1Sfj+talS1A3DGsxl/uPB4UkRvP51TTqNOo+FfnwgJP8iUCq Cc: hybi@ietf.org Subject: Re: [hybi] Multiplex examples & continuations 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, 25 Oct 2012 13:26:58 -0000 --047d7b2e3fa83ff82d04cce2287c Content-Type: text/plain; charset=ISO-8859-1 Not sure I understand that response. (sorry) While from a reading/parsing point of view, this non-encapsulation of continuations is a trivial nuance to support. However the writing/generating side of this gets rather confusing. So let me toss 2 use cases that highlight my concern here. Use Case #1: Browser, large frames, no intermediary. The browser has established mux, and has 3 active channels. Each channel is doing roughly 2 frames a second, with an average payload length of 1024 bytes. Channel #3 now receives a big message (10MB), fragmented into 20 parts, part #1 is 500k. This message takes a while to send. (let say the connection is a mobile phone on 3G) Meanwhile, Channel #2 wants to also send a large message. However, due to the continuations not being encapsulated or assigned to a Channel ID, then Channel #2 cannot start to send its message until Channel #3 has finished sending its Continuation + FIN frame. Use Case #2: WebSocket + Mux aware corporate proxy. An advanced web proxy setup at a corporation, handles WebSocket, understands mux. If a connection from the proxy out the internet to a web host that supports mux is detected, then all WAN side websocket traffic, regardless if the WAN side end point supports mux or not is proxied through this 1 LAN side mux connection transparently. In this scenario, channels wanting to send large messages with continuations, again block all other channels wanting to use large messages. There are clues in the spec that Use Case #1 can be handled via the various flow control / send quota / new channel slot techniques in the protocol. However, even those flow controls don't seem to indicate how to resolve this large message + non-encapsulated continuations situation. >From a receiving point of view, the important message details (TEXT+!FIN, CONT+!FIN, ... , CONT+FIN) is either not preserved with the spec as it is, or there is a likely scenario of blocking of other channels during large messages, or I'm reading the spec wrong (the most likely case, heh) -- Joakim Erdfelt On Thu, Oct 25, 2012 at 1:39 AM, Takeshi Yoshino wrote: > Current multiplexing spec is message-based. It's no longer based on > frame-to-frame encapsulation approach. Each WebSocket "message" carries one > original frame. > > In this example, the message (fragmented into two frames) carries > 0x01(channel 1) 0x81(FIN, TEXT) "Hello world" that was originally 0x81 0x11 > "Hello world" on the multiplexed connection (channel 1). > > This allows intermediaries that doesn't understand multiplexing to safely > change fragmentation of received data without knowledge of multiplexing. > > --047d7b2e3fa83ff82d04cce2287c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not sure I understand that response. (sorry)

While from a read= ing/parsing point of view, this non-encapsulation of continuations is a tri= vial nuance to support.
However the writing/generating side of th= is gets rather confusing.

So let me toss 2 use cases that highlight my concern he= re.

Use Case #1: Browser, large frames, no interme= diary.

The browser has established mux, and has 3 = active channels.
Each channel is doing roughly 2 frames a second, with an average paylo= ad length of 1024 bytes.
Channel #3 now receives a big message (1= 0MB), fragmented into 20 parts, part #1 is 500k.
This message tak= es a while to send. (let say the connection is a mobile phone on 3G)
Meanwhile, Channel #2 wants to also send a large message.
Ho= wever, due to the continuations not being encapsulated or assigned to a Cha= nnel ID, then Channel #2 cannot start to send its message until Channel #3 = has finished sending its Continuation + FIN frame.

Use Case #2: WebSocket + Mux aware corporate proxy.

An advanced web proxy setup at a corporation, handles= WebSocket, understands mux.
If a connection from the proxy out t= he internet to a web host that supports mux is detected, then all WAN side = websocket traffic, regardless if the WAN side end point supports mux or not= is proxied through this 1 LAN side mux connection transparently.
In this scenario, channels wanting to send large messages with continu= ations, again block all other channels wanting to use large messages.
=


There are clues in the spec that Us= e Case #1 can be handled via the various flow control / send quota / new ch= annel slot techniques in the protocol.
However, even those flow controls don't seem to indicate how to re= solve this large message + non-encapsulated continuations situation.
<= div>From a receiving point of view, the important message details (TEXT+!FI= N, CONT+!FIN, ... , CONT+FIN) is either not preserved with the spec as it i= s, or there is a likely scenario of blocking of other channels during large= messages, or I'm reading the spec wrong (the most likely case, heh)

--
Joakim Erdfelt <joakim@intalio.com>



On Thu, Oct 25, 2012 at 1:39 AM, Takeshi= Yoshino <tyoshino@google.com> wrote:
Current multiplexing spec is message-based.= It's no longer based on frame-to-frame encapsulation approach. Each We= bSocket "message" carries one original frame.

In this example, the message (fragmented into two frames) carries 0x01= (channel 1) 0x81(FIN, TEXT) "Hello world" that was originally 0x8= 1 0x11 "Hello world" on the multiplexed connection (channel 1).

This allows intermediaries that doesn't understand = multiplexing to safely change fragmentation of received data without knowle= dge of multiplexing.


--047d7b2e3fa83ff82d04cce2287c-- From tyoshino@google.com Thu Oct 25 09:01:07 2012 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 D9CF721F892B for ; Thu, 25 Oct 2012 09:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.101 X-Spam-Level: X-Spam-Status: No, score=-103.101 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DxlwyLdnyh1 for ; Thu, 25 Oct 2012 09:01:07 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D848E21F8901 for ; Thu, 25 Oct 2012 09:01:06 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so2794266iec.31 for ; Thu, 25 Oct 2012 09:01: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:x-system-of-record; bh=Ho0/OOfkRyXPPwLfHZiZ/kCpOCulrdZVO49MT19naBk=; b=Av3iexW4sxGeLvgeIxCCaoXftxT6S2ryebOejXqNrnS3bG+7qWFUVR4erSIhxsjpjU rLtZwJ8N3J0RbKty7zejTWCnnRTZ4wsFvgAeJafm8LQeXAJKzJ4vlq3EHBowl2cP0PIv 8ZCws8r8tBDQ8wqzFtT26rB62x5/BhdL/drIMXxjeY+pPDOLvRWGNAUSoITuxQJrmyby TXxLGwtEqdNHwjPU0Gvq8IlNpcOSvTJ+s7uDRymbBeX4EGKWd5hFrXjgB04whllaXQoz J2acIj/f5ph+BcNw9QBF4Zmv23buKyDinW/Yaf3GFh72FZPBXYCNcHfisQdLxKPQ/E88 TfGw== 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-system-of-record:x-gm-message-state; bh=Ho0/OOfkRyXPPwLfHZiZ/kCpOCulrdZVO49MT19naBk=; b=X34uoNEQ3h1l1RC3fvvb1d9466gaXAZB35o8uc7QGaau/UDPfibkH602rU3qaPMCfk t85762tfuPxUcT3rtHHp7OphNyW3qaWEq+O2X0OZ7XFc9OY7InXidv6J1nY3NXl/WEYb n37eQmiiEF+rZTG4NnQAXwbGFW6FSgEP9KDr2gi7yPA4L9IwltyiFQHQgwMyy50qE9ej V9fH7g+JCAoyJ10G3QLGZPivk9/GLFYJN6zasiLdizy8urokMotrA4yX+YrMJjfMFheG THwbUCHRusdm3W3VCH80wPemqhEMVmeST1syugEsN4RRDf85qYqqk7BuanLZ4D7PDibk hzHA== Received: by 10.50.185.200 with SMTP id fe8mr6398427igc.35.1351180866404; Thu, 25 Oct 2012 09:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.240.7 with HTTP; Thu, 25 Oct 2012 09:00:45 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Fri, 26 Oct 2012 01:00:45 +0900 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=14dae934067391c02e04cce44fed X-System-Of-Record: true X-Gm-Message-State: ALoCoQlJQ15YFmQm/hisfK0zuVkCzMEIe3UkyakdQOnr6MxrnJmHaED2hPmtIPtWBk+LJX882qw3qEyLywDEj+Wavop7RwdgAYdHa4hVdKJ+cP9RauY0XQJ/kxodgjp+qxtJB1WoS7Jf0f9NpCknTqTzFXtZQ8sLBOGvyeVH+phNa9mwSl1eJ4Lwo0M98ZzEVo0w2SfS+M3N Cc: hybi@ietf.org Subject: Re: [hybi] Multiplex examples & continuations 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, 25 Oct 2012 16:01:08 -0000 --14dae934067391c02e04cce44fed Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 10:26 PM, Joakim Erdfelt wrote: > Not sure I understand that response. (sorry) > > While from a reading/parsing point of view, this non-encapsulation of > continuations is a trivial nuance to support. > However the writing/generating side of this gets rather confusing. > > So let me toss 2 use cases that highlight my concern here. > > Use Case #1: Browser, large frames, no intermediary. > > The browser has established mux, and has 3 active channels. > Each channel is doing roughly 2 frames a second, with an average payload > length of 1024 bytes. > Channel #3 now receives a big message (10MB), fragmented into 20 parts, > part #1 is 500k. > This message takes a while to send. (let say the connection is a mobile > phone on 3G) > Meanwhile, Channel #2 wants to also send a large message. > However, due to the continuations not being encapsulated or assigned to a > Channel ID, then Channel #2 cannot start to send its message until Channel > #3 has finished sending its Continuation + FIN frame. > > Please take a look at the third example. You can insert the large message of the Channel #2 between the 500k chunks of the Channel #3. Each of the 500k chunks are converted into encapsulating messages by multiplexor like: (FIN=true, op=Binary) (Mask=false, LEN=500k+2) (channel ID=2) (FIN=false, op=) <...500kBdata...> (FIN=true, op=Binary) (Mask=false, LEN=500k+2) (channel ID=2) (FIN=false, op=continuation) <...500kBdata...> ... (FIN=true, op=Binary) (Mask=false, LEN=500k+2) (channel ID=2) (FIN=true, op=continuation) <...500kBdata...> Channel #2's large message e.g. (FIN=true, op=text) (mask=false, len=100k) is converted into an encapsulating message: (FIN=true, op=Binary) (Mask=false, LEN=100k+2) (channel ID=3) (FIN=true, op=text) So, the following is a valid sequence of encapsulating messages without any ambiguity: (FIN=true, op=Binary) (Mask=false, LEN=500k+2) (channel ID=2) (FIN=false, op=) <...500kBdata...> (FIN=true, op=Binary) (Mask=false, LEN=100k+2) (channel ID=3) (FIN=true, op=text) (FIN=true, op=Binary) (Mask=false, LEN=500k+2) (channel ID=2) (FIN=false, op=continuation) <...500kBdata...> ... (FIN=true, op=Binary) (Mask=false, LEN=500k+2) (channel ID=2) (FIN=true, op=continuation) <...500kBdata...> The second example in the spec is just saying that we can fragment messages output by multiplexor (Note that here we're manipulating output of multiplexor. We're not multiplexor. So at this point it's not allowed to reorder messages to interleave messages encapsulating frames of different channels.) Maybe, it was confusing that I placed example #2 (that is just telling that multiplexor's output is safe to be fragmented) before example #3 that is explaining how multiplexing is done. > Use Case #2: WebSocket + Mux aware corporate proxy. > > An advanced web proxy setup at a corporation, handles WebSocket, > understands mux. > If a connection from the proxy out the internet to a web host that > supports mux is detected, then all WAN side websocket traffic, regardless > if the WAN side end point supports mux or not is proxied through this 1 LAN > side mux connection transparently. > In this scenario, channels wanting to send large messages with > continuations, again block all other channels wanting to use large messages. > > > There are clues in the spec that Use Case #1 can be handled via the > various flow control / send quota / new channel slot techniques in the > protocol. > However, even those flow controls don't seem to indicate how to resolve > this large message + non-encapsulated continuations situation. > From a receiving point of view, the important message details (TEXT+!FIN, > CONT+!FIN, ... , CONT+FIN) is either not preserved with the spec as it is, > or there is a likely scenario of blocking of other channels during large > messages, or I'm reading the spec wrong (the most likely case, heh) > > -- > Joakim Erdfelt > > > > On Thu, Oct 25, 2012 at 1:39 AM, Takeshi Yoshino wrote: > >> Current multiplexing spec is message-based. It's no longer based on >> frame-to-frame encapsulation approach. Each WebSocket "message" carries one >> original frame. >> >> In this example, the message (fragmented into two frames) carries >> 0x01(channel 1) 0x81(FIN, TEXT) "Hello world" that was originally 0x81 0x11 >> "Hello world" on the multiplexed connection (channel 1). >> >> This allows intermediaries that doesn't understand multiplexing to safely >> change fragmentation of received data without knowledge of multiplexing. >> >> > --14dae934067391c02e04cce44fed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2012 at 10:26 PM, Joakim Erdfelt <joakim@intalio.com&= gt; wrote:
Not sure I understand that response. (sorry)

While from a read= ing/parsing point of view, this non-encapsulation of continuations is a tri= vial nuance to support.
However the writing/generating side of th= is gets rather confusing.

So let me toss 2 use cases that highlight my concern he= re.

Use Case #1: Browser, large frames, no interme= diary.

The browser has established mux, and has 3 = active channels.
Each channel is doing roughly 2 frames a second, with an average paylo= ad length of 1024 bytes.
Channel #3 now receives a big message (1= 0MB), fragmented into 20 parts, part #1 is 500k.
This message tak= es a while to send. (let say the connection is a mobile phone on 3G)
Meanwhile, Channel #2 wants to also send a large message.
Ho= wever, due to the continuations not being encapsulated or assigned to a Cha= nnel ID, then Channel #2 cannot start to send its message until Channel #3 = has finished sending its Continuation + FIN frame.


Please take a l= ook at the third example. You can insert the large message of the Channel #= 2 between the 500k chunks of the Channel #3.

Each of the 500k chunks are converted into encapsulating messages by multip= lexor like:
(FIN=3Dtrue, op=3DBinary) (Mask=3Dfalse, LEN=3D5= 00k+2) (channel ID=3D2) (FIN=3Dfalse, op=3D<type of the message>) <= ;...500kBdata...>
(FIN=3Dtrue, op=3DBinary) (Mask=3Dfalse, LEN=3D500k+2)= (channel ID=3D2) (FIN=3Dfalse, op=3Dcontinuation) <...500kBdata...><= /div>
...
(FIN=3Dtrue, op=3DBinary) (Mask=3D= false, LEN=3D500k+2) (channel ID=3D2) (FIN=3Dtrue, op=3Dcontinuation) <.= ..500kBdata...>

Channel #2's large message e.g. (FIN=3Dtrue, = op=3Dtext) (mask=3Dfalse, len=3D100k) <HelloHelloHello...>
= is converted into an encapsulating message:
(FIN=3Dtrue, op=3DBin= ary) (Mask=3Dfalse, LEN=3D100k+2) (channel ID=3D3) (FIN=3Dtrue, op=3Dtext) = <HelloHelloHello...>

So, the following is a valid sequence of encapsulating = messages without any ambiguity:

(FIN=3Dtrue, = op=3DBinary) (Mask=3Dfalse, LEN=3D500k+2) (channel ID=3D2) (FIN=3Dfalse, op= =3D<type of the message>) <...500kBdata...>
(FIN=3Dtrue, op=3DBinary) (Mask=3Dfalse, LEN=3D100k+2) (channel ID=3D3= ) (FIN=3Dtrue, op=3Dtext) <HelloHelloHello...>
(FIN=3Dtrue,= op=3DBinary) (Mask=3Dfalse, LEN=3D500k+2) (channel ID=3D2) (FIN=3Dfalse, o= p=3Dcontinuation) <...500kBdata...>
...
(FIN=3Dtrue, op=3DBinary) (Mask=3Dfalse, LEN=3D500k+2) (= channel ID=3D2) (FIN=3Dtrue, op=3Dcontinuation) <...500kBdata...>

The second example in the spec is just saying t= hat we can fragment messages output by multiplexor (Note that here we'r= e manipulating output of multiplexor. We're not multiplexor. So at this= point it's not allowed to reorder messages to interleave messages enca= psulating frames of different channels.)

Maybe, it was confusing that I placed example #2 (that = is just telling that multiplexor's output is safe to be fragmented) bef= ore example #3 that is explaining how multiplexing is done.
=A0
Use Case #2: WebSo= cket + Mux aware corporate proxy.

An advanced web = proxy setup at a corporation, handles WebSocket, understands mux.
If a connection from the proxy out the internet to a web host that sup= ports mux is detected, then all WAN side websocket traffic, regardless if t= he WAN side end point supports mux or not is proxied through this 1 LAN sid= e mux connection transparently.
In this scenario, channels wanting to send large messages with continu= ations, again block all other channels wanting to use large messages.
=


There are clues in the spec that Us= e Case #1 can be handled via the various flow control / send quota / new ch= annel slot techniques in the protocol.
However, even those flow controls don't seem to indicate how to re= solve this large message + non-encapsulated continuations situation.
<= div>From a receiving point of view, the important message details (TEXT+!FI= N, CONT+!FIN, ... , CONT+FIN) is either not preserved with the spec as it i= s, or there is a likely scenario of blocking of other channels during large= messages, or I'm reading the spec wrong (the most likely case, heh)

--
Joakim Erdfelt <joakim@intalio.com>



On Thu, Oct 25, 2012 at 1:39 AM, Takeshi= Yoshino <tyoshino@google.com> wrote:
Current multiplexing spec is message-based.= It's no longer based on frame-to-frame encapsulation approach. Each We= bSocket "message" carries one original frame.

In this example, the message (fragmented into two frames) carries 0x01= (channel 1) 0x81(FIN, TEXT) "Hello world" that was originally 0x8= 1 0x11 "Hello world" on the multiplexed connection (channel 1).

This allows intermediaries that doesn't understand = multiplexing to safely change fragmentation of received data without knowle= dge of multiplexing.



--14dae934067391c02e04cce44fed-- From tyoshino@google.com Fri Oct 26 00:24:28 2012 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 8B5E921F8496 for ; Fri, 26 Oct 2012 00:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.797 X-Spam-Level: X-Spam-Status: No, score=-102.797 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8THq2mqpq+6c for ; Fri, 26 Oct 2012 00:24:27 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A43C621F848A for ; Fri, 26 Oct 2012 00:24:27 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3826994iec.31 for ; Fri, 26 Oct 2012 00:24: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 :cc:content-type:x-system-of-record; bh=YAdy+dxM/uXXjUae2y9AqIUquKZsc00SZSAoi6CDJIc=; b=a9WrecbOiOgDbCFIQwmNyAg+pwqpNVdUXcEzYSuz3F5hhlIA7IgmZtqmTm/rei8riS TTjmIw4XgEQxkFzlcKTdtoBEFVEF2xqUal4qKXQBgNs9vPZvc9M7f72gGCzzOwoAfIb8 Gmaz3iR+dsohxMpBVjGpdnwJMJh4n83/oP621um5zWlRzkOvMOZW4c5wX3XhVnbOaccj //9mdxH2rJXXYIOwskRXtHBv1PInM9KrbHw8e5QQnI+GKimQUB9SLvBpjIQpAy7G7rSn FQZnpXypmsAWXB8mu1Yny8j774/hzTn0KaV3Xygsz//8BYEAesRDKfLLgyqJKbCHutv6 invA== 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-system-of-record:x-gm-message-state; bh=YAdy+dxM/uXXjUae2y9AqIUquKZsc00SZSAoi6CDJIc=; b=SQKHtde8GpXYkkS/vejKAG/vBlE/53Z80H6CKvbNyxNgdYXTmHk63C0QxqcnleWgtv CPP1xxR6vVYqOWqzEy8Qr67skEMnQM4CHZR973dcw8ySVi8hy1jOys6+7ynXfI/VJLJR UsNAOwlusT4e3Tbz1A9hxwX81hjz61APNtn2KQL9PNilRFFn4Ahi9cyIidnFkskfy8Rc mN81mp8lu1HTSu6Ne93HZaXxhFJ3u4wpxbn93OO1n4HTU6uL83iZMDrSkpNXqYBwx+c4 SSWxRY/wNJAM6TiJ1gVURDl8F0ztP4BIBPApSooc6bzxlDfXqztzbjcRppsB9Ows8Z8e o1Tw== Received: by 10.50.183.199 with SMTP id eo7mr1232667igc.36.1351236267100; Fri, 26 Oct 2012 00:24:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.240.7 with HTTP; Fri, 26 Oct 2012 00:24:06 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Fri, 26 Oct 2012 16:24:06 +0900 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=14dae934042db54c6c04ccf135b3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlaE+eJXScznPhQ/Vd16NVe8mpR2SVDzgFG92stGHebxa3m22Qgg6ng6McR1CvGlUbfD36BzG9WigdsrbMLdT3TkNNLFpdyUvGdOq0tStS6hEeA5hLojGUO2EHzpYtlEgVN76DxOjrsh0r0Bbz2TZI5ET3FRKEhUrVXj2n63KDjw4TTHofrVj9SfZH7WpA7yoeotQq3 Cc: hybi@ietf.org Subject: Re: [hybi] Multiplex examples & continuations 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, 26 Oct 2012 07:24:28 -0000 --14dae934042db54c6c04ccf135b3 Content-Type: text/plain; charset=ISO-8859-1 This is revised version of the Examples section to be published as -09. Changed the order of examples. 10. Examples _This section is non-normative._ The examples below assume the handshake has already completed and the multiplexing extension was negotiated. Quotes are for clarity. Frames of encapsulating messages from client to server MUST be masked. The examples below are not masked for simplicity. 0x82 0x0d 0x01 0x81 "Hello world" This is a non-fragmented text message of "Hello world" on logical channel 1 encapsulated into a non-fragmented encapsulating message. 0x82 0x07 0x01 0x01 "Hello" 0x82 0x08 0x01 0x80 " world" This is a text message of "Hello world" fragmented into two frames of "Hello" and " world" on logical channel 1 encapsulated into two non-fragmented encapsulating messages. A multiplexor may change fragmentation of a message before encapsulation like this so that frames of other logical channels (including the control channel) can be injected in the middle of the message. 0x82 0x07 0x01 0x01 "Hello" 0x82 0x05 0x02 0x81 "bye" 0x82 0x08 0x01 0x80 " world" This example shows how data for two logical channels are interleaved. There're three non-fragmented encapsulating messages. As explained in the previous example, the text message of "Hello world" is split into two frames before encapsulation. The first and third frame in this example contain each of the two fragments of the text message of "Hello world" on logical channel 1. The second frame contains a non-fragmented text message of "bye" on logical channel 2. 0x82 0x04 0x01 0x01 "Te" 0x82 0x04 0x01 0x09 "Pi" 0x82 0x04 0x01 0x80 "ng" 0x82 0x04 0x01 0x80 "xt" A ping message "Ping" is injected in the middle of a text message "Text" on the original connection. The multiplexor fragmented the ping message due to some reason into two fragments. 0x02 0x07 0x01 0x81 "Hello" 0x80 0x06 " world" Encapsulating messages output from the multiplexor can be fragmented by intermediaries without knowledge of the Multiplexing Tamplin & Yoshino Expires April 29, 2013 [Page 28] Internet-Draft A Multiplexing Extension for WebSockets October 2012 Extension. This is an example of a fragmented encapsulating message. It's equivalent to the first example as a message. 0x82 0x15 0x00 0x01 0x02 0x12 "GET / HTTP/1.1" 0x0d 0x0a 0x0d 0x0a This is a message on the control channel carrying one AddChannelRequest. The first two octets are the WebSocket headers. The 3rd octet is logical channel ID field of 0. The 4th octet has opcode, RSV and Enc field. Objective channel ID is 2. The handshake is delta-encoded. --14dae934042db54c6c04ccf135b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is revised version of the Examples section to be published as -09= . Changed the order of examples.


10. =A0Examples

=A0 = =A0_This section is non-normative._

=A0 =A0The examples below assume the handshake has alre= ady completed and the
=A0 =A0multiplexing extension was negotiate= d. =A0Quotes are for clarity.

=A0 =A0Frames of enc= apsulating messages from client to server MUST be
=A0 =A0masked. =A0The examples below are not masked for simplicity.

=A0 =A00x82 0x0d 0x01 0x81 "Hello world"

=A0 =A0 =A0 This is a non-fragmented text message o= f "Hello world" on logical
=A0 =A0 =A0 channel 1 encapsulated into a non-fragmented encapsulating=
=A0 =A0 =A0 message.

=A0 =A00x82 0x07 0= x01 0x01 "Hello" 0x82 0x08 0x01 0x80 " world"

=A0 =A0 =A0 This is a text message of "Hello world" fragmented in= to two frames
=A0 =A0 =A0 of "Hello" and " world&q= uot; on logical channel 1 encapsulated into two
=A0 =A0 =A0 non-f= ragmented encapsulating messages. =A0A multiplexor may change
=A0 =A0 =A0 fragmentation of a message before encapsulation like this = so that
=A0 =A0 =A0 frames of other logical channels (including t= he control channel)
=A0 =A0 =A0 can be injected in the middle of = the message.

=A0 =A00x82 0x07 0x01 0x01 "Hello" 0x82 0x05 = 0x02 0x81 "bye" 0x82 0x08 0x01
=A0 =A00x80 " world= "

=A0 =A0 =A0 This example shows how data for= two logical channels are
=A0 =A0 =A0 interleaved. =A0There're three non-fragmented encapsul= ating
=A0 =A0 =A0 messages. =A0As explained in the previous examp= le, the text message
=A0 =A0 =A0 of "Hello world" is sp= lit into two frames before encapsulation.
=A0 =A0 =A0 The first and third frame in this example contain each of = the two
=A0 =A0 =A0 fragments of the text message of "Hello = world" on logical channel
=A0 =A0 =A0 1. =A0The second frame= contains a non-fragmented text message of
=A0 =A0 =A0 "bye" on logical channel 2.

=
=A0 =A00x82 0x04 0x01 0x01 "Te" 0x82 0x04 0x01 0x09 "Pi= " 0x82 0x04 0x01 0x80
=A0 =A0"ng" 0x82 0x04 0x01 0= x80 "xt"

=A0 =A0 =A0 A ping message "Ping" is injected= in the middle of a text message
=A0 =A0 =A0 "Text" on = the original connection. =A0The multiplexor fragmented the
=A0 = =A0 =A0 ping message due to some reason into two fragments.

=A0 =A00x02 0x07 0x01 0x81 "Hello" 0x80 0x06 = " world"

=A0 =A0 =A0 Encapsulating messa= ges output from the multiplexor can be
=A0 =A0 =A0 fragmented by = intermediaries without knowledge of the Multiplexing



Tamplin & Yoshino =A0= =A0 =A0 =A0Expires April 29, 2013 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page 28]=
=0C
Internet-Draft =A0 A Multiplexing Extension for We= bSockets =A0 =A0October 2012


=A0 =A0 =A0 Extension. =A0This is an exa= mple of a fragmented encapsulating
=A0 =A0 =A0 message. =A0It'= ;s equivalent to the first example as a message.

= =A0 =A00x82 0x15 0x00 0x01 0x02 0x12 "GET / HTTP/1.1" 0x0d 0x0a 0= x0d 0x0a

=A0 =A0 =A0 This is a message on the control channel ca= rrying one
=A0 =A0 =A0 AddChannelRequest. =A0The first two octets= are the WebSocket
=A0 =A0 =A0 headers. =A0The 3rd octet is logic= al channel ID field of 0. =A0The 4th
=A0 =A0 =A0 octet has opcode, RSV and Enc field. =A0Objective channel = ID is 2.
=A0 =A0 =A0 The handshake is delta-encoded.
<= /div>

--14dae934042db54c6c04ccf135b3-- From tyoshino@google.com Mon Oct 29 01:52:42 2012 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 4EE7B21F846D for ; Mon, 29 Oct 2012 01:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGuyhhV-z3+h for ; Mon, 29 Oct 2012 01:52:41 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 997B021F8464 for ; Mon, 29 Oct 2012 01:52:41 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7080850iec.31 for ; Mon, 29 Oct 2012 01:52:41 -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:x-system-of-record; bh=JUtkZ0N3lisw/zRLM5ahCj7HHVslIy2JEjf292L35T0=; b=H0LVbqvnZdh/MEgvMnZ8UBQPHt/WHDsRpemqJERQBJD7TAYzBCPEBgVi/9jgtpnCbI /ltzpjLQsp2MrXL8RCY6eQXdSZqwlJP1m2abYd3TSbFIX7CXdj7qwjqCOdrYkymu5pei 4ulXAJtUqbXRHRyYJa59hP/MVDDY7rKc9EVNXei9UECM+fqU0voo4dCpNJIAquNbkIzU wV9+aIYBEI/q/lwLeB6PNnn8b8uyyMaHo8YBHWSWni1JWSuMKUZV6azuaG3RORHBy4Nv r5JqrWvkk9dxUeWgVFbm9DeRMbboZ/eqyVzoQz9PhDS67TbM/ILrk+65BvhkE8iQUaiY J7ew== 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-system-of-record:x-gm-message-state; bh=JUtkZ0N3lisw/zRLM5ahCj7HHVslIy2JEjf292L35T0=; b=IQ0NlDlkwiIs4fCbg2zkjFwYQOpbj8IitZBe8O0qzGycCLuBngn+o4jepMl85fBoG1 6lzA9ORE2+GMNAVDuX5gZZUB+5mww4PhRNe3XFCvX8gguR3QtVMHxwbTuOf2tlnDvCYc DARPpPDhweodWNJCkl0y+EkZV+KFZudGRKhZ4KwxuTpwHDy8sdvcWY7uDB6ReRIMbtvZ RcdkqMgHfwu4bIMib4snyAEbHTQntr8c9Y8+o4xxcUTBKTeEfFfK+ZQmKsc6akDFtwJs FQLS5r0s4QslIum6RgY2xALJFMIKrOhBXkgwIOgcjx7mcbxifKz/Z0FYEnHW8sDha8Xf vkeg== Received: by 10.50.46.134 with SMTP id v6mr8802719igm.55.1351500760928; Mon, 29 Oct 2012 01:52:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.240.7 with HTTP; Mon, 29 Oct 2012 01:52:19 -0700 (PDT) In-Reply-To: <5087B9CB.2080604@ericsson.com> References: <5087B9CB.2080604@ericsson.com> From: Takeshi Yoshino Date: Mon, 29 Oct 2012 17:52:19 +0900 Message-ID: To: Salvatore Loreto Content-Type: multipart/alternative; boundary=14dae9340f53c4d34e04cd2eca28 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmst2CWKKtiAJkke+JLEkOB3h1MwKwtH1jIOR6K8epOnEZFEuiV0wAi6dxAxHbWIhUtuYmQVEGt5Bt26DRsIzU3XleB4Q3pj1i7eQ6GDgIJqCcqMxELSnIbcngh7ChfsnAe5aAC4d413e1taRIlPP1+mKeszgL8V0geSdA2c8arDKS+oUgidnvuGG2e38y0Zd3gVV7N Cc: hybi@ietf.org Subject: Re: [hybi] "Cache-Control: no-cache" may improve handshake success rate 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, 29 Oct 2012 08:52:42 -0000 --14dae9340f53c4d34e04cd2eca28 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 24, 2012 at 6:50 PM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > or even just on the wiki of the HyBi wg > Created a page on the wiki. http://trac.tools.ietf.org/wg/hybi/trac/wiki/ReportFromImplementers Thanks --14dae9340f53c4d34e04cd2eca28 Content-Type: text/html; charset=ISO-8859-1
On Wed, Oct 24, 2012 at 6:50 PM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
or even just on the wiki of the HyBi wg

Created a page on the wiki.

Thanks
--14dae9340f53c4d34e04cd2eca28-- From joakim@intalio.com Tue Oct 30 16:47:11 2012 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 B72C221F8545 for ; Tue, 30 Oct 2012 16:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.409 X-Spam-Level: X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i99Y0zzrotDx for ; Tue, 30 Oct 2012 16:47:11 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 01C5021F8543 for ; Tue, 30 Oct 2012 16:47:10 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so530983pad.31 for ; Tue, 30 Oct 2012 16:47:10 -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 :x-gm-message-state; bh=HsVUJIGCSVh/oJQ9/i36Ctz1mOjdDtdMm9CbY3OtWX8=; b=XR0nsu7QqnswLLLIEq45EVflwZONmxnimo+75AEttoP8jWSPXUg0w/Bw60bC+JiDOd VECt3p06LyBs4Cc46Dc6yRUVTp0zrvJf6AvyngxaKqXqHC9GyWIvfrQtxjXTrRABoOJu waWZax+W5ljITjtUWcxV7pVr7GZspcih5gG7SbVNJegkv7qzJqXCHWNHN2ymwVM7OzIq z9seUP8JfSC/iaOMoi/i81+JYtgSqkmYfGvZacB1hal7c0uFCQ2Qc6P4NOMUDu+rLVRN iO1smA1d3cISRxuA7ozsZPhMGpxwBO+IDCaN250J83kW9ZBE9IH6xUfy5941sJRGGXmH NhzQ== MIME-Version: 1.0 Received: by 10.68.241.133 with SMTP id wi5mr106940699pbc.48.1351640830600; Tue, 30 Oct 2012 16:47:10 -0700 (PDT) Received: by 10.66.77.162 with HTTP; Tue, 30 Oct 2012 16:47:10 -0700 (PDT) Date: Tue, 30 Oct 2012 16:47:10 -0700 Message-ID: From: Joakim Erdfelt To: hybi@ietf.org Content-Type: multipart/alternative; boundary=047d7b339cd592672704cd4f6775 X-Gm-Message-State: ALoCoQlOrSjp0PYX67h61N8XN9FBgBlgNdPTrUu0cBFQsS8+U0NoN+pMk+6t/+pFTGaruo9EB50J Subject: [hybi] Mux / Delta encoded AddChannel Request/Response 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, 30 Oct 2012 23:47:11 -0000 --047d7b339cd592672704cd4f6775 Content-Type: text/plain; charset=ISO-8859-1 During Mux AddChannelRequest, with a delta-encoded handshake, are there any expectation of merging multi-value headers (like Cookie) with the original request or response if present in the delta as well? -- Joakim Erdfelt webtide.com / eclipse.org/jetty / cometd.org --047d7b339cd592672704cd4f6775 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
During Mux AddChannelRequest, with a delta-encoded handshake, are=A0th= ere any expectation of merging multi-value headers (like Cookie) with the o= riginal request or response if present in the delta as well?

--
Joakim Erdfelt <joakim@intalio.com>

--047d7b339cd592672704cd4f6775-- From tyoshino@google.com Tue Oct 30 21:57:21 2012 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 8728721F8615 for ; Tue, 30 Oct 2012 21:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmsNJmjHuiuD for ; Tue, 30 Oct 2012 21:57:21 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C900B21F84EE for ; Tue, 30 Oct 2012 21:57:20 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1218549vcb.31 for ; Tue, 30 Oct 2012 21:57:20 -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:x-system-of-record; bh=FtUjAU4WY3ZHbZHiJ3rLf1ZNitM7tmGii7SsENQgvhk=; b=XCdEEtlmN0U+Z4f0M2S5VZCFEk7+SopXATfYFmNb8yKn69ojx2dJX6cyhYU10LDm2Y AEwmFmn4EbbitAEfGsWpWhyceZ6qbg043T2BLIGTsH1CnGNkTcunw7QBgaUbWfAzsGSM njQKIBv2oXl1X3YJ/H6SuYSgTSdX/9GukOCQ6G+S7k6vMqZHqno9w7cWvW2k1EMmx31r Dko2NB8eQisZiICN4Mqt/JQdYE5KIVpr+9A9MjZX7h7WY2OU+cQn0NH4aIG68ZIAZgv2 LuhD9NDaOME6sVGhNYh06vTGpkaZyTi45sOau70tb01qNSIdC2BHbw5Ixw0DlNU4p8fd JT5A== 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-system-of-record:x-gm-message-state; bh=FtUjAU4WY3ZHbZHiJ3rLf1ZNitM7tmGii7SsENQgvhk=; b=c/KDBoMJrtzsf/v1Kz8xrFoBwVi4/NnC6srEGgz8nrZSG3jqnQTdcLcQPX/J/8Bsez KPttUulYIAs07tQVMmwqoww+ncr4ir04l8VAOkVdt++W9YhX4Kln4tbn0H7fjxv/t4Rp C5pd6A3aQcwJzG6N+uSsd3qCBRFJnYWYrkPhRCXnSogVuPfbmALhPVdHoeHbf1TFI3Tq NqKf5aKe9udScycQBhdV+nyNnvgIY6tu6QgXuWCAoszH408XXCYJ1elscKHfaK3OHMvK R83jzo5o7LhHcZW9+hXmr+SBR2LbHPBwZEEArIQU+7rzgIKDTftFF91/z18UnH/WmV/l UANA== Received: by 10.220.149.142 with SMTP id t14mr16749659vcv.46.1351659439418; Tue, 30 Oct 2012 21:57:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.106.106 with HTTP; Tue, 30 Oct 2012 21:56:59 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Wed, 31 Oct 2012 13:56:59 +0900 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=f46d043c8220be6bbc04cd53bc7b X-System-Of-Record: true X-Gm-Message-State: ALoCoQnyKTNtnhi0MI1/bPyfqpnnO4gqLfN5xcfyS6vuXDl1nIrx3OyOFOh9wywgKuVViZEefERd+eLKnCHjzf2xTomnRc7zWIXSfhCja6QgtBby/A7mknv69CYoP88v9AaW+2JNkIzEkeEJ0PZ3TsyZfszAKNhdLbJ2rZB3DM9Xo0qgTDBGLgVkUvYrtM1EIorjg2gIYMdR Cc: hybi@ietf.org Subject: Re: [hybi] Mux / Delta encoded AddChannel Request/Response 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, 31 Oct 2012 04:57:21 -0000 --f46d043c8220be6bbc04cd53bc7b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 31, 2012 at 8:47 AM, Joakim Erdfelt wrote: > During Mux AddChannelRequest, with a delta-encoded handshake, are there > any expectation of merging multi-value headers (like Cookie) with the > original request or response if present in the delta as well? > Thanks for pointing it out. How about: - keep it allowed to send multiple headers with the same name as-is when the identity encoding is used - all such headers are merged [1] into single headers when -- the handshake is set to delta-base -- the handshake is sent using delta-encode [1] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21#section-3.2 --f46d043c8220be6bbc04cd53bc7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 31, 2012 at 8:47 AM, Joakim Erdfelt = <joakim@intalio.com> wrote:
During Mux AddChannelRequest, with a delta-encoded handshake, are=A0th= ere any expectation of merging multi-value headers (like Cookie) with the o= riginal request or response if present in the delta as well?

Thanks for pointing it out. How about:
- keep it a= llowed to send multiple headers with the same name as-is when the=A0identit= y encoding=A0is used
- all such headers are merged [1] into singl= e headers when
-- the handshake is set to delta-base
-- the handshake is se= nt using delta-encode


--f46d043c8220be6bbc04cd53bc7b-- From joakim@intalio.com Wed Oct 31 09:46:10 2012 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 4AD3821F862D for ; Wed, 31 Oct 2012 09:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8fn9kgzMSec for ; Wed, 31 Oct 2012 09:46:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 498A021F8605 for ; Wed, 31 Oct 2012 09:46:08 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1111266pbb.31 for ; Wed, 31 Oct 2012 09:46:06 -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=GMx4IXuCcCqXZAtKLO/DABKu4V6/1ZaKnFOUS74CyYM=; b=C2AG4adnM8lbg00E7tE8dswUjXIwgRr2sgyR2GZAx8srAmrNFLcuXuzTeeQUcgu8ra eAQYoH0Trt1rIoMR/HT6dyJJ/omtZOhzXhMzf77WXY+k2rCrBvUpUYgpumF80is49iJ0 yUE+j8gjbqcyyInyrvfVbCDIL5WRryCFgkbkGXZFsu++8WszgfHFjTONd2PEJrMoYTnZ RN1tho5OqJHmPDdAFcXQNthWAXynGMKX23EOR+qxeUGJFbJuUzJYRjnk8xiN+HWklaLI XvYWNUyp7vlCERP1NxdXJ6WWyE5Ndcl0xBMLo6BJNZWyWHb7qJ08VfdwEkitcupx6AOI DVlg== MIME-Version: 1.0 Received: by 10.66.78.199 with SMTP id d7mr103625084pax.77.1351701966845; Wed, 31 Oct 2012 09:46:06 -0700 (PDT) Received: by 10.66.77.162 with HTTP; Wed, 31 Oct 2012 09:46:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Oct 2012 09:46:06 -0700 Message-ID: From: Joakim Erdfelt To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=f46d042de8d793765f04cd5da3c0 X-Gm-Message-State: ALoCoQn+Y0RiluW0k4JlHWDarl8imbF7R3W7GfJ9x28UcW2g4m5GNiEhp8eHOYkgiMhEIbA/Subq Cc: hybi@ietf.org Subject: Re: [hybi] Mux / Delta encoded AddChannel Request/Response 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, 31 Oct 2012 16:46:10 -0000 --f46d042de8d793765f04cd5da3c0 Content-Type: text/plain; charset=ISO-8859-1 Some thoughts we had. First thought, how would we merge multiple Cookie headers in a request? Looks like https://tools.ietf.org/html/rfc6265#section-5.4 answers that for us. MUST NOT for client requests. What about multiple Set-Cookie response headers? https://tools.ietf.org/html/rfc6265#section-4.1 says SHOULD NOT for servers. Might need some language in the mux spec to say this becomes MUST NOT for mux. However, https://tools.ietf.org/html/rfc2616#section-4.2 says that multiple message headers of the same name is allowed. Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded. This makes the merging of a delta encoded set of headers rather complex. (how can we ensure no change in sematics for example? in order for delta encoding to work in this case, we would need a way to remove full headers as well, right?) Do we want to just outright specify what headers in the mux AddChannelRequest and AddChannelResponse are allowed to be sent, and all other headers are stripped (or cause a failed AddChannel as its likely the request isn't for websocket?) Or can we just drop the delta encoding requirement? -- Joakim Erdfelt On Tue, Oct 30, 2012 at 9:56 PM, Takeshi Yoshino wrote: > On Wed, Oct 31, 2012 at 8:47 AM, Joakim Erdfelt wrote: > >> During Mux AddChannelRequest, with a delta-encoded handshake, are there >> any expectation of merging multi-value headers (like Cookie) with the >> original request or response if present in the delta as well? >> > > Thanks for pointing it out. How about: > - keep it allowed to send multiple headers with the same name as-is when > the identity encoding is used > - all such headers are merged [1] into single headers when > -- the handshake is set to delta-base > -- the handshake is sent using delta-encode > > [1] > http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21#section-3.2 > > --f46d042de8d793765f04cd5da3c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Some thoughts we had.

First thought, how woul= d we merge multiple Cookie headers in a request?
Looks like=A0https://tools.ietf= .org/html/rfc6265#section-5.4=A0answers that for us.
MUST NOT for client requests.

What about mult= iple Set-Cookie response headers?
Might need some language in the mux spec to say this becomes MUST NOT = for mux.

However,=A0https://tools.ietf.org/html/rfc2616#section-4= .2=A0says that multiple message headers of the same name is allowed. 

   Multiple message-header fields with the same fi=
eld-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics=
 of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

This makes the merging of a delta encoded set of= headers rather complex. (how can we ensure no change in sematics for examp= le? =A0in order for delta encoding to work in this case, we would need a wa= y to remove full headers as well, right?)
Do we want to just outright specify what headers in the mux AddChannel= Request and AddChannelResponse are allowed to be sent, and all other header= s are stripped (or cause a failed AddChannel as its likely the request isn&= #39;t for websocket?)
Or can we just drop the delta encoding requirement?

--
Joakim Erdfelt <joakim@intalio.com>



On Tue, Oct 30, 2012 at 9:56 PM, Takeshi= Yoshino <tyoshino@google.com> wrote:
On Wed, Oct 31, 2012 at 8:47 A= M, Joakim Erdfelt <joakim@intalio.com> wrote:
During Mux AddChannelRequest, with a delta-encoded handshake, are=A0th= ere any expectation of merging multi-value headers (like Cookie) with the o= riginal request or response if present in the delta as well?

Thanks for pointing it out. How about:
- kee= p it allowed to send multiple headers with the same name as-is when the=A0i= dentity encoding=A0is used
- all such headers are merged [1] into= single headers when
-- the handshake is set to delta-base
-- the handshake is se= nt using delta-encode



--f46d042de8d793765f04cd5da3c0-- From salvatore.loreto@ericsson.com Wed Oct 31 11:54:24 2012 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 7A31E21F863F for ; Wed, 31 Oct 2012 11:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.76 X-Spam-Level: X-Spam-Status: No, score=-105.76 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf-VqwT5-gLS for ; Wed, 31 Oct 2012 11:54:23 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB7821F8617 for ; Wed, 31 Oct 2012 11:54:18 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-9f-509173d83ba7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A0.5A.26143.8D371905; Wed, 31 Oct 2012 19:54:16 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 31 Oct 2012 19:54:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4495728F1 for ; Wed, 31 Oct 2012 20:54:16 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AB99153A97 for ; Wed, 31 Oct 2012 20:54:15 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6070B539E2 for ; Wed, 31 Oct 2012 20:54:15 +0200 (EET) Message-ID: <509173D7.2020402@ericsson.com> Date: Wed, 31 Oct 2012 20:54:15 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: hybi@ietf.org References: <508686AB.4000409@ericsson.com> In-Reply-To: <508686AB.4000409@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvre6N4okBBtOeWlm8f7mNyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGdcmNzEVnOGsmN63l62B8SZ7FyMHh4SAiUTfdI4uRk4gU0zi wr31bF2MXBxCAicZJfat7oVyNjBKNJzcxQxSJSRwjlGi67QLROIgo8T2p+9ZIJxTjBJrd/1h A6niFdCW6PvwigXEZhFQlTj5/hJYN5uAmcTzh1vAbFGBZIm1n56wQ9QLSpyc+QSsXgTI7t66 BqxGWKBA4sO5P4wQm7Ul1k36BVbDKaAj8aL3NJjNLGArcWHOdShbXmL72znMEP+oSVw9twnq ai2J3rOdTBMYRWYhWTcLSfssJO0LGJlXMbLnJmbmpJcbbWIEhvLBLb9VdzDeOSdyiFGag0VJ nNd66x5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYx5+0w59H0itv8tNwx5f2OFxr0pTYkb vRVXrnqw5tE2nR/Tr1ev52IJb7T4N3mHhMhfxpIzdq+fbODetn6q/3Jp0XLx87k3K64wWtuu umDfe91AbrNcxfP1LfHqMQy56qcjJKQ1pJ9vvH8srMP2bPneO898NvrxOrdzCU77sPW9nYCr dKDP3jNKLMUZiYZazEXFiQDySRXtMwIAAA== Subject: Re: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th) 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, 31 Oct 2012 18:54:24 -0000 just a reminder! WGLC for the draft-ietf-hybi-permessage-compression-04 is on going. So please, read and review the draft and send to the mailing list all your technical and/or editorial comments, concerns and feedback in general you have. thanks Salvatore -- Salvatore Loreto, PhD www.sloreto.com On 10/23/12 2:59 PM, Salvatore Loreto wrote: > Hi there, > > this message initiates a three-weeks working group last call (WG LC) > on draft-ietf-hybi-permessage-compression-04 > to be completed on November 14th: > > http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-04 > > > At this point, we haven't seen any objection on the core design of > this extension for quite long, > all the feedback/clarification-requests raised in the mailing list > have been addressed by the Takeshi. > > > Note: to clarify to those not so familiar with the IETF process, a WG > LC is a final check within the working group to prepare a draft > to be ready for subsequent submission to the IESG > > Thanks, > Gabriel and Salvatore > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > From webmaster@zaphoyd.com Wed Oct 31 14:49:19 2012 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 74F1821F883C for ; Wed, 31 Oct 2012 14:49:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGCJaSVECD0y for ; Wed, 31 Oct 2012 14:49:18 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id BBC8921F8558 for ; Wed, 31 Oct 2012 14:49:17 -0700 (PDT) Received: from c-68-51-76-178.hsd1.il.comcast.net ([68.51.76.178]:40241 helo=[10.0.1.88]) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TTg9z-0005VU-7g for hybi@ietf.org; Wed, 31 Oct 2012 17:49:16 -0400 From: Peter Thorson Content-Type: multipart/alternative; boundary="Apple-Mail=_BCCA8255-28E2-41D3-A3DE-7A5911FBCD68" Message-Id: <9F33F43E-CA1D-4B58-B460-A5C1DD297510@zaphoyd.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Wed, 31 Oct 2012 16:49:11 -0500 References: <508686AB.4000409@ericsson.com> <509173D7.2020402@ericsson.com> To: "hybi@ietf.org" In-Reply-To: <509173D7.2020402@ericsson.com> X-Mailer: Apple Mail (2.1499) 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-Source: X-Source-Args: X-Source-Dir: Subject: Re: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th) 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, 31 Oct 2012 21:49:19 -0000 --Apple-Mail=_BCCA8255-28E2-41D3-A3DE-7A5911FBCD68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, I've been working on implementing permessage-compress the past week as = an aid to reviewing the extension. It is not complete yet, but I have a = few notes so far and a question. First a question: are there any existing implementations of = permessage-compress (either client or server) suitable for me to test = interoperability with? *Feedback on permessage-compress* Regarding Extension Negotiation Section 3. Extension Negotiation describes the grammar of the list of = compression method descriptions. It references `token` in the ABNF. Is = token universally defined in ABNF? Or does token here refer to the = definition of token from RFC2616(HTTP 1.1)? In RFC6455 (Websocket = Protocol), which also uses RFC2616 tokens explicitly mentions this and = cites RFC2616 for the definition of token. If indeed the token syntax from HTTP 1.1 is intended it might be worth = citing either RFC6455 or RFC2616 as the source for the `token` ABNF. Overall, this section is largely similar to section 9.1 (Extension = Negotiation) of RFC6455 except with less detail (specifically: no = mention of the borrowed HTTP 1.1 semantics including critical reminders = of things like the implied *LWS rules). If each extension is going to = include the exact details of extension negotiation I'd suggest that it = include all of this language. Alternatively, a much simpler description = of extension negotiation that refers the reader to RFC6455 section 9.1 = for the details might be appropriate. Some minor english issues: Abstract: Current: It compresses the payload of non-control WebSocket messages = using specified compression algorithm. Potential correction: It compresses the payload of non-control WebSocket = messages using a specified compression algorithm. Introduction: Current: This extension negotiates what compression method to use on = opening handshake, ... Potential correction: This extension negotiates what compression method = to use during the opening handshake, ... *Some observations from my work implementing this extension* This is not really related to this extension specifically, but rather an = observation about the negotiation system already specified in RFC6455 = that can be ignored until attempting to support an extension for the = first time. The use of the full HTTP 1.1 header field data list syntax = adds considerable complexity for any implementation that doesn't already = have access to a mature HTTP header parsing library. WebSocket = implementations sans extensions can get by with drastically simplified = header parsing logic (for better or for worse). The introduction of = extensions with complex negotiation parameters requires a more complete = header parsing system. I suspect this will be an area in need of careful = testing and defenses against incomplete implementations. The introduction of compression introduces a number of issues that = should be taken into account, especially for low level/embedded users = and servers needing very high numbers of concurrent connections. These = aren't criticisms or even specific to permessage-compress, just = observations that other implementations might find useful and are = different than the compression issues typically found in traditional = HTTP servers. - Additional buffering and copying can result in lower performance than = you might expect from just the additional compression work - Compression breaks a number of optimizations that servers can use to = reduce CPU and memory usage like outgoing message = preparation/de-duplication. - Compression drastically increases per connection memory usage. This = can be mitigated somewhat at a compression efficiency loss via the = window bits and context takeover parameters, but it requires adequate = library support and in some cases cooperation of the remote endpoint.=20 Whether compression makes sense or with what settings does it make sense = will depend highly on expected workload, one size fits all defaults may = not be effective. Documentation should make it clear that there are = non-trivial tradeoffs to enabling compression for certain workloads = (especially high concurrency short message ones). Servers and libraries = especially may need to provide options and documentation to allow users = to tune resource usage based on their expected workloads. best, Peter Thorson On Oct 31, 2012, at 13:54 , Salvatore Loreto = wrote: > just a reminder! >=20 > WGLC for the draft-ietf-hybi-permessage-compression-04 is on going. >=20 > So please, read and review the draft and send to the mailing list > all your technical and/or editorial comments, concerns and feedback in = general you have. >=20 >=20 >=20 > thanks > Salvatore >=20 > --=20 > Salvatore Loreto, PhD > www.sloreto.com >=20 >=20 >=20 > On 10/23/12 2:59 PM, Salvatore Loreto wrote: >> Hi there, >>=20 >> this message initiates a three-weeks working group last call (WG LC) = on draft-ietf-hybi-permessage-compression-04 >> to be completed on November 14th: >>=20 >> http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-04 >>=20 >>=20 >> At this point, we haven't seen any objection on the core design of = this extension for quite long, >> all the feedback/clarification-requests raised in the mailing list = have been addressed by the Takeshi. >>=20 >>=20 >> Note: to clarify to those not so familiar with the IETF process, a WG = LC is a final check within the working group to prepare a draft >> to be ready for subsequent submission to the IESG >>=20 >> Thanks, >> Gabriel and Salvatore >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >>=20 >>=20 >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --Apple-Mail=_BCCA8255-28E2-41D3-A3DE-7A5911FBCD68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Potential correction: It compresses the = payload of non-control WebSocket messages using a specified compression = algorithm.

Introduction:
Current= : This extension negotiates what compression method to use on opening = handshake, ...
Potential correction: This extension negotiates what = compression method to use during the opening handshake, = ...

*Some observations from my work = implementing this extension*

This is not really = related to this extension specifically, but rather an observation about = the negotiation system already specified in RFC6455 that can be ignored = until attempting to support an extension for the first time. = The use of the full HTTP 1.1 header field data list syntax adds = considerable complexity for any implementation that doesn't already have = access to a mature HTTP header parsing library. WebSocket = implementations sans extensions can get by with drastically simplified = header parsing logic (for better or for worse). The introduction of = extensions with complex negotiation parameters requires a more complete = header parsing system. I suspect this will be an area in need of careful = testing and defenses against incomplete = implementations.

The introduction of = compression introduces a number of issues that should be taken into = account, especially for low level/embedded users and servers needing = very high numbers of concurrent connections. These aren't criticisms or = even specific to permessage-compress, just observations that other = implementations might find useful and are different than the compression = issues typically found in traditional HTTP servers.
- = Additional buffering and copying can result in lower performance than = you might expect from just the additional compression work
- = Compression breaks a number of optimizations that servers can use to = reduce CPU and memory usage like outgoing message = preparation/de-duplication.
- Compression drastically = increases per connection memory usage. This can be mitigated somewhat at = a compression efficiency loss via the window bits and context takeover = parameters, but it requires adequate library support and in some cases = cooperation of the remote = endpoint. 

Whether compression makes sense = or with what settings does it make sense will depend highly on expected = workload, one size fits all defaults may not be = effective. Documentation should make it clear that there are = non-trivial tradeoffs to enabling compression for certain workloads = (especially high concurrency short message ones). Servers and libraries = especially may need to provide options and documentation to allow users = to tune resource usage based on their expected = workloads.

best,

Pe= ter Thorson


On Oct 31, 2012, at = 13:54 , Salvatore Loreto <salvatore.loreto@ericsson.co= m> wrote:

just a reminder!

WGLC for the = draft-ietf-hybi-permessage-compression-04 is on going.

So please, = read and review the draft and send to the mailing list
all your = technical and/or editorial comments, concerns and feedback in general = you have.



thanks
Salvatore

--
Salvatore = Loreto, PhD
www.sloreto.com



On = 10/23/12 2:59 PM, Salvatore Loreto wrote:
Hi = there,

this message initiates a three-weeks working group last = call (WG LC) on draft-ietf-hybi-permessage-compression-04
to be = completed on November = 14th:

http://tools.ietf.org/html/draft-ietf-hybi-permessage-compres= sion-04


At this point, we haven't seen any objection on the = core design of this extension for quite long,
all the = feedback/clarification-requests raised in the mailing list have been = addressed by the Takeshi.


Note: to clarify to those not so = familiar with the IETF process, a WG LC is a final check within the = working group to prepare a draft
to be ready for subsequent = submission to the IESG

Thanks,
Gabriel and = Salvatore
_______________________________________________
hybi = mailing = list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi


_______________________________________________
h= ybi mailing = list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi

= --Apple-Mail=_BCCA8255-28E2-41D3-A3DE-7A5911FBCD68--