Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-04.txt

From: [email-masked]
Date: Tue, 07 Aug 2012 07:00:29 -0700

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-04.txt
	Pages           : 38
	Date            : 2012-08-07

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 [email-masked] 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-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-multiplexing-04

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

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 9 Aug 2012 01:02:40 +0900

Hi all,

Here's -03 -> -04 change summary

- added Extension Negotiation section
- defined drop reason codes
- removed F frag from DropChannel
- changed length header encoding in multiplex control blocks to the same
encoding as payload length
- clarified which headers AddChannelRequest/Response inherit from physical
connection handshake
- clarified how the server should respond to AddChannelRequest
- added physical channel fallback suggestion bit to NewChannelSlot
- removed nesting consideration section

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 9 Aug 2012 11:42:57 +0900

re: change on number encoding

I support John's argument made here about channel ID encoding.
http://www.ietf.org/mail-archive/web/hybi/current/msg09555.html

Smaller overhead is expected when number of active channels is small. But
payload length is not a good fit for this. Channel ID is independent from
message size. The cost doesn't become negligible even when the assigned ID
is big.

But still use of 3 types of number encoding seemed not so good. So, instead
of channel ID, I've replaced number fields in multiplex control blocks
which were representing "size". 3B and 9B overhead are negligible as the
data they're representing gets bigger. Replenished send quota field is not
followed by data, but big quota is sent expecting big data. I think it's
reasonable to take it as negligible cost for a channel with such traffic.
You can just reuse the code for read/write the RFC 6455 payload length.