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

From: [email-masked]
Date: Wed, 04 Jul 2012 00:59:51 -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-03.txt
	Pages           : 35
	Date            : 2012-07-04

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

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

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

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 4 Jul 2012 17:13:12 +0900

Hi all,

I just published the new version of multiplexing extension.

Changes
- [main change] channel ID tagging by Extension data field -> encapsulate
each frame into a binary "message" together with channel ID
- text for "multiplexed connection" term definition
- don't inherit extension tokens after mux (including itself) from the
handshake for the physical connection
- moved objective channel ID field into Opc specific data area as we've
added NewChannelSlot command that is channel independent

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 18 Jul 2012 15:32:19 +0900

I'm planning to make small change on quota spending rule.

Now quota mechanism considers only the length of payload data. This allows
a bad logical channel to flood the connection with zero-sized messages.
I'll add kinda penalty of 1 octet quota consumption to each encapsulated
message in addition to its payload data length.

So, a message "Hello" spends 6 byte of send quota. If fragmented like "Hel"
"lo", still spends 6 byte. An empty message spends 1 byte.

I'm going to add just 1 byte tax to each message, not each encapsulated
frame. Multiplexing may fragment messages to fit remaining quota. If
fragmentation also affects quota consumption, implementation would be
complicated.

Thoughts?

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 18 Jul 2012 16:28:03 +0900

Hello Takeshi,

> fragmentation also affects quota consumption, implementation would be

What about an attacker fragmenting messages on purpose? And why adding 
1? Why not add the actual header length, which is the actual cost?

Regards,   Martin.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 18 Jul 2012 16:53:38 +0900

Hello Martin,

On Wed, Jul 18, 2012 at 4:28 PM, "Martin J. Dürst"
<[email-masked]>wrote:

> What about an attacker fragmenting messages on purpose?

Multiplexer may de-fragment them (e.g. zero-sized message as 10000 frames)
into smaller number of frames. When interleaved with control frames, each
control frame also consumes 1+ byte quota.

> And why adding 1? Why not add the actual header length, which is the
> actual cost?
>

To address the dead lock concern perfectly, I thought it's better not to
spend quota more than 1 byte for the minimum unit of transmission.

As it's up to 10 byte, I agree it wouldn't be a big problem like
the per-frame compression's fragmentation lock issue. Using the length of
the original header may be also fine.

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 18 Jul 2012 11:09:27 +0300

If we would envelope the entire traffic produced by the logical channel
(complete frames including headers) then we would not have this problem,
plus WS mux would be able to multiplex any protocol (e.g. SPDY) and not only
WebSocket frames.

WBR,

Arman

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Yoshino
Sent: Wednesday, July 18, 2012 10:54 AM
To: Martin J. Dürst
Cc: [email-masked]
Subject: Re: [hybi] I-D Action:
draft-ietf-hybi-websocket-multiplexing-03.txt

Hello Martin,

On Wed, Jul 18, 2012 at 4:28 PM, "Martin J. Dürst" <[email-masked]>
wrote:

Hello Takeshi,

And why adding 1? Why not add the actual header length, which is the actual
cost?

As it's up to 10 byte, I agree it wouldn't be a big problem like the
per-frame compression's fragmentation lock issue. Using the length of the
original header may be also fine.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 19 Jul 2012 14:31:23 +0900

On Wed, Jul 18, 2012 at 5:09 PM, Arman Djusupov <[email-masked]> wrote:

> plus WS mux would be able to multiplex any protocol (e.g. SPDY) and not
> only WebSocket frames.****
>
> **
>
It's hard to sell because of its extra overhead compared to non-muxed. I
think we cannot reach consensus by entire traffic enveloping.