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

From: [email-masked]
Date: Wed, 10 Oct 2012 02:29:09 -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-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 [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-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/

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 10 Oct 2012 18:33:04 +0900

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, <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 10 Oct 2012 03:34:08 -0700

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?

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."

Cheers,
Tobias

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 10 Oct 2012 20:03:44 +0900

Hello Tobias,

On Wed, Oct 10, 2012 at 7:34 PM, Tobias Oberstein <
[email-masked]> 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.

> "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."

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 10 Oct 2012 21:35:13 +0900

On Wed, Oct 10, 2012 at 8:55 PM, Arman Djusupov <[email-masked]> 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.
>

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 10 Oct 2012 17:04:38 +0300

See my answer inline.

From: Takeshi Yoshino [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Wednesday, October 10, 2012 3:35 PM
To: Arman Djusupov
Cc: Tobias Oberstein;  <mailto:[email-masked]> [email-masked]
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."

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).

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

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

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

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 11 Oct 2012 12:41:14 +0900

On Wed, Oct 10, 2012 at 11:04 PM, Arman Djusupov <[email-masked]> wrote:

> ** **
> quota problems we had with 0 bytes frames.****
>
> I see.

> WebSocket frames."****
> ** **
> delta-compression on headers. It needs involvement of multiplexing.****
>
> ** **
>
> 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.
>
> 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****
> negotiation****
> protocol of the logical channel****
>
> - include nothing else in the handshake portion of the AddChannelRequest**
> **
>
> 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.****
>
> ** **
>
> method duplicates length info. That's not the best thing to do.****
>
> ** **
>
> frames, it’s 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.

---

From: "Arman Djusupov" <[email-masked]>
Date: Thu, 11 Oct 2012 11:42:52 +0300

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

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. 

Something like that is also possible.

With best regards,

Arman

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 12 Oct 2012 00:11:29 +0900

On Thu, Oct 11, 2012 at 5:42 PM, Arman Djusupov <[email-masked]> wrote:

> 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).

> the 31 bit Stream ID and 24 bit length header used by SPDY.
Yes. We can map them.

> ****
> 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.