Subject: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 7 Jan 2014 16:36:17 +0900

Hi all,

We've been working on mux extension to make WebSocket scalable for long
time, but as SPDY got widely supported and adopted quickly, now there seems
to be no longer any good reason to continue this work which is WebSocket
dedicated.

Scalability is still important issue to address. From now, I'd like to
focus on WS/SPDY effort which we've been working on in parallel with the
mux extension.

Please take a look at the latest proposal in this post.
https://groups.google.com/forum/#!topic/spdy-dev/aJut2ax3glc

If you really want the dedicated mux extension than one over SPDY, sorry
but please take over the work.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 07 Jan 2014 17:10:43 +0900

Hello Takeshi,

> focus on WS/SPDY effort which we've been working on in parallel with the

I think not having a WebSocket-specific mux extension is the right way 
to go. But in the end, I'm much more interested in WS/HTTP2 than in 
WS/SPDY. Do you have a plan with respect to WS/HTTP2?

Regards,   Martin.

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 7 Jan 2014 17:37:27 +0900

Hi Martin,

On Tue, Jan 7, 2014 at 5:10 PM, "Martin J. Dürst" <[email-masked]>wrote:

> I think not having a WebSocket-specific mux extension is the right way to
> go.

If there's real need to continue the work, I'll support the work. But I'd
like to ask someone else to take over or co-edit the spec.

> But in the end, I'm much more interested in WS/HTTP2 than in WS/SPDY. Do
> you have a plan with respect to WS/HTTP2?
>
>
Yes. We'd like to standardize WS/HTTP/2.0 eventually. It depends on how
quickly HTTP/2.0 is standardized and adopted and how SPDY is going to
evolve, which protocol is stable, ready and good for running experiment,
etc. We plan to coordinate with httpbis and SPDY team to figure out how to
drive standardization and implementation.

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 9 Jan 2014 01:11:06 -0800

Hi Takeshi,

it's a pity, but I can understand the motivation to shove everything into HTTP2.

Anyway, some questions:

1) Frame Mapping
"""
One WebSocket frame is mapped into one preceding SPDY HEADERS frame and following plural SPDY data frames. The SPDY HEADERS frame must contain WebSocket frame fields and following SPDY data frames contain payload data. These data frames are free to be reframed.
"""
https://docs.google.com/document/d/124vB5NV1p2N55wg-MdXaUW0VICmCfc7ukw9aWzSHijk/edit

So reframing of WebSocket frames (the payload) into multiple SPDY data frames MAY occur, but does not need to occur? And a WS/SPDY implementation is free to choose the boundaries within WS frame payload at which to reframe into different SPDY data frames as it likes?

2) End of WS Frame

The end of a WS message is signaled with a SPDY data frame having MSG_DONE set.

How is the end of a WS frame signaled, given that the WS frame may have been reframed into multiple SPDY data frames?

3) WS extension

Are WS extensions fully supported? In particular, is "permessage-deflate" supported when running WS/SPDY?

Thanks!
/Tobias

Von: hybi [mailto:[email-masked]] Im Auftrag von Takeshi Yoshino
Gesendet: Dienstag, 7. Januar 2014 08:36
An: [email-masked]
Betreff: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

Hi all, 

We've been working on mux extension to make WebSocket scalable for long time, but as SPDY got widely supported and adopted quickly, now there seems to be no longer any good reason to continue this work which is WebSocket dedicated.

Scalability is still important issue to address. From now, I'd like to focus on WS/SPDY effort which we've been working on in parallel with the mux extension.

If you really want the dedicated mux extension than one over SPDY, sorry but please take over the work.

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 9 Jan 2014 18:36:36 +0900

Hi Tobias,
Thank you for the comments.

1) Frame Mapping
> """
> One WebSocket frame is mapped into one preceding SPDY HEADERS frame and
> following plural SPDY data frames. The SPDY HEADERS frame must contain
> WebSocket frame fields and following SPDY data frames contain payload data.
> These data frames are free to be reframed.
> """
>
> So reframing of WebSocket frames (the payload) into multiple SPDY data
> frames MAY occur, but does not need to occur? And a WS/SPDY implementation
> is free to choose the boundaries within WS frame payload at which to
> reframe into different SPDY data frames as it likes?

A WebSocket frame MAY be split to multiple SPDY DATA frames.
Intermediaries MAY merge SPDY DATA frames and MAY split a SPDY DATA frame
into multiple DATA frames.
Is this answering your question?

> How is the end of a WS frame signaled, given that the WS frame may have
> been reframed into multiple SPDY data frames?

When you receive a HEADERS frame, you can recognize that the last SPDY
frame is that last frame in a WebSocket frame.
When you receive a SPDY frame with MSG_DONE, you can recognize that it is
the last SPDY frame in a WebSocket message and hence the last SPDY frame in
a WebSocket frame.

> supported when running WS/SPDY?

Yes. We have reserved bits and we can emulate the opening handshake, I
think.

On Thu, Jan 9, 2014 at 6:11 PM, Tobias Oberstein <
[email-masked]> wrote:

> One WebSocket frame is mapped into one preceding SPDY HEADERS frame and
> following plural SPDY data frames. The SPDY HEADERS frame must contain
> WebSocket frame fields and following SPDY data frames contain payload data.
> These data frames are free to be reframed.
> """
>
> So reframing of WebSocket frames (the payload) into multiple SPDY data
> frames MAY occur, but does not need to occur? And a WS/SPDY implementation
> is free to choose the boundaries within WS frame payload at which to
> reframe into different SPDY data frames as it likes?
>
> 2) End of WS Frame
>
> How is the end of a WS frame signaled, given that the WS frame may have
> been reframed into multiple SPDY data frames?
>
> 3) WS extension
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 9 Jan 2014 01:45:41 -0800

Two more thoughts:

1) WS/SPDY

WS essentially provides a reliable, ordered, bidirectional/full-duplex message based channel.

WS/SPDY is layering WS over SPDY.

Are there efforts to implement a WebSocket-like semantics (like above) _directly_ using SPDY facilities?

2) WS Mux

As it stands (as far as I understand), SPDY MUX and the WS/MUX both roughly target the same semantics:

multiplex different channels over one underlying transport

The channels are independent. There is no ordering implied across data sent over _different_ logical channels.

In the case of WS/SPDY, that means, there is no ordering implied between WS messages sent over different SPDY-multiplexed channels.

Now, I can see a need for a different semantics (see my old mails/comments wrt to WS/MUX):

Have a per-message priority that allows (weak) reordering of respective messages on a _single_ channel:

Two WS messages (and frames for that) MAY be reordered ("prioritized") by the transport channel as follows:

Msg-A MAY overtake Msg-B, if and only if, Priority(Msg-A) > Priority(Msg-B)

Use case / scenario: chat (high prio) and file transfer (low prio) both running over 1 WS for 1 app

Is there interest in above?

Would it make sense to start an effort for that (retargeting the WS/MUX goals)?

/Tobias

Hi all,

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 9 Jan 2014 01:53:49 -0800

Hi Yutaka,

1) Yes, I understand. Thanks!

2) Ok, both WS frame and message boundaries are preserved.

But: I cannot recognize the end of a WS frame until the next WS frame starts (for which I receive a HEADERS frame, which is the implicit signal that the previous WS frame ended), right?

And if so, why is there no FRAME_DONE bit on the SPDY frame that corresponds to the end of a WS frame?

3) Ok, great! Hope this works, since SPDY provides header compression, but no sophisticated bidirectional payload compression as "WS permessage-deflate" does.

Cheers,
/Tobias

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Yutaka Hirano
Gesendet: Donnerstag, 9. Januar 2014 10:37
An: Tobias Oberstein
Cc: Takeshi Yoshino; [email-masked]
Betreff: Re: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

Hi Tobias,

1) Frame Mapping
"""
Intermediaries MAY merge SPDY DATA frames and MAY split a SPDY DATA frame into multiple DATA frames.

2) End of WS Frame
The end of a WS message is signaled with a SPDY data frame having MSG_DONE set.
How is the end of a WS frame signaled, given that the WS frame may have been reframed into multiple SPDY data frames?
When you receive a HEADERS frame, you can recognize that the last SPDY frame is that last frame in a WebSocket frame.
When you receive a SPDY frame with MSG_DONE, you can recognize that it is the last SPDY frame in a WebSocket message and hence the last SPDY frame in a WebSocket frame.

3) WS extension
Are WS extensions fully supported? In particular, is "permessage-deflate" supported when running WS/SPDY?
Yes. We have reserved bits and we can emulate the opening handshake, I think.

On Thu, Jan 9, 2014 at 6:11 PM, Tobias Oberstein <[email-masked]<mailto:[email-masked]>> wrote:
Hi Takeshi,

Anyway, some questions:

1) Frame Mapping
"""

2) End of WS Frame

3) WS extension

Thanks!
/Tobias

Von: hybi [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von Takeshi Yoshino
Gesendet: Dienstag, 7. Januar 2014 08:36
An: [email-masked]<mailto:[email-masked]>
Betreff: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

Hi all,

If you really want the dedicated mux extension than one over SPDY, sorry but please take over the work.
_______________________________________________
hybi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/hybi

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 09 Jan 2014 20:51:53 +0900

This is a problem that I have already encountered in three different 
applications, and think there must/should be a well-known solution for. 
It's not strictly standards-related, but I'm sending it to this lists 
because I think that's where the experts are.

It's about detecting broken connections on the application level. 
Setting up a WS connection and using it while it's working is very easy. 
However, what is supposed to happen when e.g. the server dies or the 
cable gets cut (directly or figuratively), or the PC is put to sleep for 
a while, and then wakes up again?

The WS API is explicit about the fact that there is no way from 
JavaScript to generate PINGs or check for PONGs. So do I just create my 
own, application level equivalent, and send a ping-like message every so 
often and assume the connection is dead when I don't get a reply 
"soonish"? Are there libraries that support such a mechanism? Or is 
every browser supported to regularly PINGPONG with the server, and call 
the onclose function when there's no answer?

Any advice or pointers appreciated!

Regards,   Martin.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 9 Jan 2014 20:59:36 +0900

> _directly_ using SPDY facilities?

I don't know for now. As we already have WS API, there's no reason to
re-invent something else and ignore WS API.

> In the case of WS/SPDY, that means, there is no ordering implied between
> WS messages sent over different SPDY-multiplexed channels.
>
>
>

Possible but no ideas. Do you want messages with the same priority never be
reordered?

>  /Tobias
>
>
>
>
>
>
>
>
>
> *Von:* hybi [mailto:[email-masked]] *Im Auftrag von *Takeshi
> Yoshino
> *Gesendet:* Dienstag, 7. Januar 2014 08:36
> *An:* [email-masked]
> *Betreff:* [hybi] Discontinuation of mux standardizaton in favor of
> WS/HTTP/2.0
>
>
>
> Hi all,
>
>
>

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 9 Jan 2014 04:11:28 -0800

Hi Takeshi,

1) What I meant is keep the WS API (I suppose you mean the one in HTML5), but layer WS-like messaging directly on SPDY, doing away with the reframing/double-framing with WS/SPDY

2) Yes, messages with equal priority must never be reordered.

One problem with standard WS is that there cannot be more than one message in flight: if a large (possible fragmented) low prio message has been started, but not yet completed, the frames for a subsequently started high-prio message cannot overtake the former.

Not sure yet how that would work (if at all) with the mechnism that WS extensions allow.

3) Regarding HTML5 API: will JavaScript have the option to open WS/SPDY connections providing channel priority? So that an app can open >1 logical WS channels, with different priorities.

/Tobias

Von: Takeshi Yoshino [mailto:[email-masked]]
Gesendet: Donnerstag, 9. Januar 2014 13:00
An: Tobias Oberstein
Cc: [email-masked]
Betreff: Re: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

On Thu, Jan 9, 2014 at 6:45 PM, Tobias Oberstein <[email-masked]<mailto:[email-masked]>> wrote:
Two more thoughts:

1) WS/SPDY

I don't know for now. As we already have WS API, there's no reason to re-invent something else and ignore WS API.

2) WS Mux

Possible but no ideas. Do you want messages with the same priority never be reordered?

/Tobias

Hi all,

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 9 Jan 2014 04:13:41 -0800

> The WS API is explicit about the fact that there is no way from JavaScript to
> generate PINGs or check for PONGs. So do I just create my own, application
> level equivalent, and send a ping-like message every so often and assume

You can have a WS server that does automatic ping-pong for connection keep-alive/loss-detection.

Or you can do it on app level from JS.

> the connection is dead when I don't get a reply "soonish"? Are there libraries
> that support such a mechanism? Or is every browser supported to regularly
> PINGPONG with the server, and call the onclose function when there's no

As far as I know, there is no JS API where you could request the browser to do automatic ping-pong upon opening a WS connection.

> answer?

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 9 Jan 2014 21:31:41 +0900

On Thu, Jan 9, 2014 at 9:11 PM, Tobias Oberstein <
[email-masked]> wrote:

> Hi Takeshi,
>
>
>
> 1) What I meant is keep the WS API (I suppose you mean the one in HTML5),
> but layer WS-like messaging directly on SPDY,
>

Sorry for asking for clarification repeatedly.

Do you mean layering WS protocol like messaging over HTTP/1.1 over SPDY? If
so, it has been discussed at spdy-dev@ and was in older spec draft.

> doing away with the reframing/double-framing with WS/SPDY
>

Hmm, current proposal is kinda direct use of SPDY. Please elaborate.

> One problem with standard WS is that there cannot be more than one message
> in flight: if a large (possible fragmented) low prio message has been
> started, but not yet completed, the frames for a subsequently started
> high-prio message cannot overtake the former.
>
>
>

Is there any use cases in your mind that cannot be addressed by having WS
connections with different prio multiplexed over one TCP connection by SPDY
mechanism?

>  3) Regarding HTML5 API: will JavaScript have the option to open WS/SPDY
> connections providing channel priority? So that an app can open >1 logical
> WS channels, with different priorities.
>
>
>

Yeah, if your answer to my question above is no, then you need that kind of
API.

>  /Tobias
>
>
>
>
>
> *Von:* Takeshi Yoshino [mailto:[email-masked]]
> *Gesendet:* Donnerstag, 9. Januar 2014 13:00
> *An:* Tobias Oberstein
> *Cc:* [email-masked]
> *Betreff:* Re: [hybi] Discontinuation of mux standardizaton in favor of
> WS/HTTP/2.0
>
>
>

---

From: "Arman Djusupov" <[email-masked]>
Date: Thu, 9 Jan 2014 16:46:03 +0200

Hello Takeshi,

In the current draft, the description of the compression process states :

   1.  Compress all the octets of the payload of the message using
       DEFLATE.

This doesn’t take into account outbound messages of arbitrary size that NEED to be fragmented, for which it is more favorable to use fragmentation and to compress & send fragments until the end of the message is reached.

In such cases the implementation buffers the input from its source and then flushes it out into a compressed fragment, repeating this process until the end of the source data is reached. At that point it flushes any remaining bytes buffered into a final frame, or flushes a final frame of 0 length.

When the implementation produces compressed fragments, it periodically produces frames with 0x00 0x00 0xFF 0xFF at the end of the frame due to flushing DEFLATE. But because of the following requirements:

   2. If the resulting data does not end with an empty DEFLATE block

       with no compression (the "BTYPE" bits is set to 00), append an

       empty DEFLATE block with no compression to the tail end.

   3.  Remove 4 octets (that are 0x00 0x00 0xff 0xff) from the tail end.

       After this step, the last octet of the compressed data contains

       (possibly part of) the DEFLATE header bits with the "BTYPE" bits

       set to 00.

the implementation must ensure that the message ends empty blocks without a trailing 0x0000FFFF, so the implementation must keep track on what type of block was at the end of the frame that was sent last. If the last frame sent ends with 0x0000FFFF then the implementation cannot remove those 4 bytes from the wire, but it must artificially produce an empty DEFLATE block to send as the final frame. This is only due to the requirement to remove 0x0000FFFF.

Wouldn’t it be easier to make the removal 0x00 0x00 0xFF 0xFF optional, while at the same time requiring that the receiving side appends a 0x00 0x00 0xFF 0xFF to the final frame in case when its missing?

It is much simpler to just check the final bytes of the message instead of having to remember the state of the previous frame.

With best regards,

Arman

---

From: Yutaka Hirano <[email-masked]>
Date: Fri, 10 Jan 2014 12:54:45 +0900

+Roberto as an HTTP2 expert.

> But: I cannot recognize the end of a WS frame until the next WS frame
> starts (for which I receive a HEADERS frame, which is the implicit signal
> that the previous WS frame ended), right?
>
You are right, you can't.

> corresponds to the end of a WS frame?

Given that WebSocket frames "have no semantic meaning" as in RFC6455, I
don't think the immediate recognition of the end of a WebSocket frame is
requisite.
I would like to introduce MSG_DONE in HTTP2 so that intermediaries that
don't fully understand WS over HTTP2 can relay it.
Since there are not so much space in FLAGS field, Introducing FRAME_DONE
may decrease the extensiveness of the spec.
Do you have a strong preference to introduce FRAME_DONE?

On Thu, Jan 9, 2014 at 6:53 PM, Tobias Oberstein <
[email-masked]> wrote:

> But: I cannot recognize the end of a WS frame until the next WS frame
> starts (for which I receive a HEADERS frame, which is the implicit signal
> that the previous WS frame ended), right?
>
>
>
> 3) Ok, great! Hope this works, since SPDY provides header compression, but
> no sophisticated bidirectional payload compression as "WS
> permessage-deflate" does.
>
>
>
> Cheers,
>
> /Tobias
>
>
>
>
>
>
>
> *Von:* [email-masked] [mailto:[email-masked]] *Im Auftrag von *Yutaka
> Hirano
> *Gesendet:* Donnerstag, 9. Januar 2014 10:37
> *An:* Tobias Oberstein
> *Cc:* Takeshi Yoshino; [email-masked]

---

From: Tobias Oberstein <[email-masked]>
Date: Fri, 10 Jan 2014 00:14:42 -0800

>You are right, you can't.
 
I have reread the proposed WS/SPDY
https://docs.google.com/document/d/124vB5NV1p2N55wg-MdXaUW0VICmCfc7ukw9aWzSHijk/edit?usp=sharing

"""
The SPDY HEADERS frame must contain WebSocket frame fields and following SPDY data frames contain payload data
"""

However:

"""
WebSocket uses MSG_DONE flag as the message boundary mark (It is not yet introduced, we should ask for the introduction). Then, “:length” and “:fin” can be omitted from HEADERS frame. Frames are delimited by a HEADERS frame.
"""

So the "length" and "fin" fields from WS frame header are omitted?

This is unfortunate, since if they would be present, the end of a WS frame (and the end of a WS message) could be readily detected.

More so: WebSocket implementations which (also) expose a frame-based API might want to signal the length of a new WS frame started right at the _beginning_. And this can't be done with the proposed WS/SPDY design also, since the frame length is only know _after_ buffering up all frame payload data, and after receiving the next SPDY HEADERS frame (implicit signal of WS frame end).

Why remove "length" and "fin" from the headers?

I think this complicates matters ..

>Given that WebSocket frames "have no semantic meaning" as in RFC6455, I don't think the immediate recognition of the end of a WebSocket frame is requisite.
>I would like to introduce MSG_DONE in HTTP2 so that intermediaries that don't fully understand WS over HTTP2 can relay it.
>Since there are not so much space in FLAGS field, Introducing FRAME_DONE may decrease the extensiveness of the spec.

The WS base protocol does not assign semantics to frame boundaries, but WS extensions might do.

This is what the spec says:

"""
Unless specified otherwise by an extension, frames have no semantic
   meaning.  An intermediary might coalesce and/or split frames, if no
   extensions were negotiated by the client and the server or if some
   extensions were negotiated, but the intermediary understood all the
   extensions negotiated and knows how to coalesce and/or split frames
   in the presence of these extensions.  One implication of this is that
   in absence of extensions, senders and receivers must not depend on
   the presence of specific frame boundaries.
"""

So if WS/SPDY does not preserve WS frame boundaries, future WS extensions which might assign semantics to frame boundaries might be incompatible with WS/SPDY.

Not that I think it's a particular good idea for WS extensions to assign semantics to frame boundaries - it's just that I think it should be a conscious decision ..

/Tobias

---

From: Tobias Oberstein <[email-masked]>
Date: Fri, 10 Jan 2014 00:37:43 -0800

>>1) What I meant is keep the WS API (I suppose you mean the one in HTML5), but layer WS-like messaging directly on SPDY,
>Do you mean layering WS protocol like messaging over HTTP/1.1 over SPDY? If so, it has been discussed at spdy-dev@ and was in older spec draft.

No, I mean a more efficient mapping of the WS _API_ to SPDY .. see below ..
 
>Hmm, current proposal is kinda direct use of SPDY. Please elaborate.

The current proposal shoehorns WS into SPDY .. eg. all that inefficient mapping of string-based key-value pairs of WS frame headers.

Why not map WS messages directly into SPDY data frames like so:

Have 2 bits in SPDY data frames:

0x03 = MSG_TYPE : 0 == text, 1 == binary
0x04 = MSG_DONE

A WS text message would simply be mapped into a series of SPDY data frames:

MSG_TYPE = 0, MSG_DONE = 0
MSG_TYPE = 0, MSG_DONE = 0
...
MSG_TYPE = 0, MSG_DONE = 1

Similar for a WS binary message.
 
Doing like above will allow to preserve the current WS API in HTML5 (which needs messages, and needs 2 message types).

It won't allow to preserve WS protocol features as in RFC6455. Personally, I wouldn't care so much.

The point is: WS/SPDY, taking together the specs involved, would seem like an incredible complex design for a simple thing: messages of 2 types over a byte stream.

==

I will continue the other discussion in a separate mail ..

/Tobias

---

From: Tobias Oberstein <[email-masked]>
Date: Fri, 10 Jan 2014 02:29:35 -0800

>>One problem with standard WS is that there cannot be more than one message in flight: if a large (possible fragmented) low prio message has been started, but not yet completed, the frames for a subsequently >>started high-prio message cannot overtake the former.
>Is there any use cases in your mind that cannot be addressed by having WS connections with different prio multiplexed over one TCP connection by SPDY mechanism?
 
Consider a messaging application where a user/app message consists of 2 parts: SUMMARY and BODY

An app that wants to send (for sync eg) 10 such app messages might want to send SUMMARYs in WS messages of high-priority, and BODYs in WS messages of low-priority, but making sure that the BODY for a application message never reaches the peer before the SUMMARY for that respective app message.

If SUMMARYs and BODYs would each be sent on 2 different channels with different priorities, the latter requirement cannot be fulfilled, since there is no ordering guarantees between messages on different channels.

A WebSocket "prioritized-messaging" extension could provide the required semantics.

>Yeah, if your answer to my question above is no, then you need that kind of API.

A guess for a per-channel-priority based protocol like WS/SPDY, a JavaScript WS API needed to expose something like the following then?

// create logical WS channel with SPDY priority 3
var channel1 = new window.WebSocket("ws://127.0.0.1:9000", ["myprotocol"], 3);

A per-message-priority WS extension however would need:

var socket = new window.WebSocket("ws://127.0.0.1:9000", ["myprotocol"]);

// send a WS message with priority 3
socket.send("Hello, world!", 3);

Cheers,
/Tobias

---

From: Tobias Oberstein <[email-masked]>
Date: Fri, 10 Jan 2014 13:11:50 -0800

>https://groups.google.com/forum/#!topic/spdy-dev/aJut2ax3glc

The current proposal

a) is unable to preserve WebSocket frame boundaries (which isn't required for plain WebSocket, but WebSocket extensions are allowed to assign semantics to WebSocket frame boundaries)
b) a single WS frame requires at least 16+n octets overhead:

WebSocket opcode and masking key are translated to SPDY HEADER frame headers: 8+n octets
WS frame payload is translated to SPDY DATA frame: 8 octets

This seems inefficient and overly complex.

Why not simply pack WebSocket frames (_including_ full WS frame header) as _payload_ of SPDY data frames only (no SPDY header frames)?

Since SPDY data frames have a payload limit of 16,383 octets, reframing might still occur, but

a) WebSocket frame boundaries are preserved exactly
b) less space (and fixed) overhead compared to above
c) simpler for existing WS implementations (SPDY data frame payload just appears as coming previously from TCP directly)

>If you really want the dedicated mux extension than one over SPDY, sorry but please take over the work.

FWIW, neither WS-MUX nor SPDY-MUX is interesting to me.

The use case of 10 browser tabs each having a WS connection open to the _same_ server is something I understand is of interest to Google - but for "normal" apps/vendors?

Further: static web resources: here, browser caching and app manifests are of more interest. And if all static resources for a single-page app are loaded, why should I pay the overhead of WS/SPDY for all the rest of the time, when the app only does messaging? WebSocket is fine. No need for SPDY nor WS/SPDY.

On the other hand, a "permessage-priority" WebSocket extension could be of interest.

==

Sidenote on SPDY: I have read more .. interestingly (to me):

"""
   Explicitly setting the priority for a stream does not guarantee any
   particular processing or transmission order for the stream relative
   to any other stream.  Nor is there any mechanism provided by which
   the initiator of a stream can force or require a receiving endpoint
   to process concurrent streams in a particular order.
"""

and

"""
A client sends an HTTP request on a new stream, using a previously unused stream identifier.
...
An HTTP request/response exchange fully consumes a single stream.
"""

Consider a RPC application protocol and an app doing 3 RPCs which do not depend in results on each other, but must be executed in-order at backend.

To do so with HTTP - _including_ SPDY or HTTP2.0 (because of above) - this _requires_ to wait for each RPC to return before initiating the next.

With WebSocket, full batching/pipelining of RPCs is possible since WebSocket guarantees strict ordering. No roundtripping. Less latency.

This is good news for WebSocket;) 

Cheers,
/Tobias

---

From: Yutaka Hirano <[email-masked]>
Date: Tue, 14 Jan 2014 19:15:51 +0900

> The WS base protocol does not assign semantics to frame boundaries, but WS

Yes, you are right. Thank you for pointing it out.

So if WS/SPDY does not preserve WS frame boundaries, future WS extensions
> which might assign semantics to frame boundaries might be incompatible with
> WS/SPDY.
>
WS/SPDY preserves WS frame boundaries, though endpoints can't recognize the
end of a WS frame immediately.

There are several ways to address this issue:
1: Use MSG_DONE for the WS frame boundaries (not WS message boundaries) and
introduce ":fin" in the HEADERS frame.
2: Introduce FRAME_DONE FLAG in SPDY frame for the WS frame boundaries.
3: Introduce ":fin" and ":length".

To reduce the size of HEADERS frames.
Though ":fin" will be well-compressed by HPACK, having ":length" increases
the overhead in a measure (around 6 bytes).

On Fri, Jan 10, 2014 at 5:14 PM, Tobias Oberstein <
[email-masked]> wrote:

> WebSocket uses MSG_DONE flag as the message boundary mark (It is not yet
> introduced, we should ask for the introduction). Then, “:length” and “:fin”
> can be omitted from HEADERS frame. Frames are delimited by a HEADERS frame.
> """
>
> This is unfortunate, since if they would be present, the end of a WS frame
> (and the end of a WS message) could be readily detected.
>
> More so: WebSocket implementations which (also) expose a frame-based API
> might want to signal the length of a new WS frame started right at the
> _beginning_. And this can't be done with the proposed WS/SPDY design also,
> since the frame length is only know _after_ buffering up all frame payload
> data, and after receiving the next SPDY HEADERS frame (implicit signal of
> WS frame end).
>
> So if WS/SPDY does not preserve WS frame boundaries, future WS extensions
> which might assign semantics to frame boundaries might be incompatible with
> WS/SPDY.
>
> Not that I think it's a particular good idea for WS extensions to assign
> semantics to frame boundaries - it's just that I think it should be a
> conscious decision ..
>
> /Tobias
>
>
>

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 14 Jan 2014 02:46:48 -0800

>WS/SPDY preserves WS frame boundaries, though endpoints can't recognize the end of a WS frame immediately.

>1: Use MSG_DONE for the WS frame boundaries (not WS message boundaries) and introduce ":fin" in the HEADERS frame.

>Though ":fin" will be well-compressed by HPACK, having ":length" increases the overhead in a measure (around 6 bytes).

What's the advantage of using SPDY HEADER frames in the context of WebSocket over SPDY?

/Tobias

---

From: Yutaka Hirano <[email-masked]>
Date: Tue, 14 Jan 2014 20:24:41 +0900

> What's the advantage of using SPDY HEADER frames in the context of

There are two advantages I think.
- Endpoints do not have to implement WebSocket framing.
  Especially if the endpoint need only WS/SPDY, not native WebSocket.
- Intermediaries can easily recognize the semantics.

On Tue, Jan 14, 2014 at 7:46 PM, Tobias Oberstein <
[email-masked]> wrote:

> >>So if WS/SPDY does not preserve WS frame boundaries, future WS
> extensions which might assign semantics to frame boundaries might be
> incompatible with WS/SPDY.
> >1: Use MSG_DONE for the WS frame boundaries (not WS message boundaries)
> and introduce ":fin" in the HEADERS frame.
> >Though ":fin" will be well-compressed by HPACK, having ":length"
> increases the overhead in a measure (around 6 bytes).
>
> Why not simply pack WebSocket frames (_including_ full WS frame header) as
> _payload_ of SPDY data frames only (no SPDY header frames)?
>

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 14 Jan 2014 03:57:17 -0800

>- Intermediaries can easily recognize the semantics.

I think it's likely that both endpoints and intermediaries that support WebSocket will either support only
native WebSocket or both native and WS/SPDY.

And in this case, it's easier to support both with just WS frames as payload of SPDY data frames. 

The current WS/SPDY proposal just complicates matters and is less efficient in terms of wire-level overhead. 

/Tobias

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 14 Jan 2014 21:40:57 +0900

Tobias, thanks for input. Yutaka is representing consensus we reached at
spdy-dev. While we respect conclusion at spdy-dev, your suggestions are
also really welcome.

Regarding cost of implementing frame parser for RFC6455 WebSocket protocol,
it's possible that a service developer chooses to accept only WebSocket
with multiplexing and backup with fallback to HTTP/1.1 COMET. In such a
case, they don't implement RFC6455 parser. So, it's not completely
unrealistic.

Takeshi

On Tue, Jan 14, 2014 at 8:57 PM, Tobias Oberstein <
[email-masked]> wrote:

> The current WS/SPDY proposal just complicates matters and is less
> efficient in terms of wire-level overhead.
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 14 Jan 2014 10:30:20 -0800

I've been lurking anyway :)

As I understand the proposal, (and it seems that Takeshi and Yukata are
covering this nicely, so what i say is probably redundant):
Message boundaries, having semantic meaning, are preserved.

Frame boundaries, having no semantic meaning, are not preserved. I don't
think it makes sense to worry about this greatly when the ability to extend
the protocol as implemented in HTTP2 is present. It doesn't make a lot of
sense to signal the frame boundaries through everything unless there is a
high-likelyhood and high-utility use-case for such. If such is found, then
HTTP2 can be revised to include it. This is the approach we've been taking
with most of the HTTP2 stuff, since there has been great effort placed on
allowing new versions to be deployed in the future.

The mapping of WS onto HTTP2 is fairly direct-- we reserved the MSG_DONE
bit specifically for this kind of use-case (i.e. bidirectional,
full-duplex, message-based).
The observation made is that there are essentially 3 types of data that
need to be preserved one way or another:
1) metadata: data about the data, e.g. text, binary, where it is supposed
to be going, etc.
2) payload
3) boundaries between these.

imho, metadata is handled with HEADERS (I'd have preferred it to be called
METADATA, but was voted down at the time :) ), payload is handled with DATA
frames, and the boundaries are delimited either through the use of HEADERS
frames, or via the MSG_DONE or STREAM_DONE bits.
In the presence of extensions, assuming that MSG_DONE is required to signal
the end of a message, then HEADERS can be used to signal any boundary
desired.

I totally agree that it would be nice to expose the priority of various
messages/channels with respect to each other. That is really an issue that
is outside the WG's purvue, though.

On Thu, Jan 9, 2014 at 7:54 PM, Yutaka Hirano <[email-masked]> wrote:

>> 3) Ok, great! Hope this works, since SPDY provides header compression,
>> but no sophisticated bidirectional payload compression as "WS

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 14 Jan 2014 11:09:29 -0800

Hi Roberto,

not sure if you agree, but FWIW, here is a summary as I see it (currently):

1) WebSocket frame boundaries _can_ have semantic meaning in WebSocket _extensions_

2) WebSocket message and frame boundaries are indeed preserved in the current WS/SPDY proposal,
however, non-final WebSocket frame ends cannot be _immediately_ detected.

3) The current WS/SPDY proposal
  * is comfortable to implement for implementations that _only_ want to implement WS/SPDY, and not native WS at the same time
 * makes things complicated for WS implementations that want to support both WS/SPDY _and_ native WS at the same time
 * has significant wire-level overhead compared to native WS (and compared to the proposal below)

I'd like to suggest a different WS/SPDY:

Pack WebSocket frames _including_ full WS frame header as _payload_ of SPDY data frames only - no SPDY header frames at all.

In the absence of negotiated WebSocket extensions (or when all WS extensions in place do not assign semantics to WS frame boundaries),

fragment WebSocket payload at the WS level such that WS frame header+payload fits into the payload of SPDY data frames.

In the latter case, this essentially adds a small SPDY data frame header (of fixed length) to WS frames. Easy to implement and efficient on wire.

IMHO, this has advantages compared to current proposal and considering 3) above.

The only disadvantage is for implementations that _only_ want to implement WS/SPDY and not native WS at the same time.

==

Regarding "permessage-priority" with ordering guarantees: should I find time and if there is interest, I'll write something up.

This could be a WebSocket extension. To be useful, the WS API in browsers would need to expose it though ..

Just my 2cts,

Tobias

Von: Roberto Peon [mailto:[email-masked]]
Gesendet: Dienstag, 14. Januar 2014 19:30
An: Yutaka Hirano
Cc: Tobias Oberstein; Takeshi Yoshino; [email-masked]
Betreff: Re: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

As I understand the proposal, (and it seems that Takeshi and Yukata are covering this nicely, so what i say is probably redundant):
Message boundaries, having semantic meaning, are preserved.

Frame boundaries, having no semantic meaning, are not preserved. I don't think it makes sense to worry about this greatly when the ability to extend the protocol as implemented in HTTP2 is present. It doesn't make a lot of sense to signal the frame boundaries through everything unless there is a high-likelyhood and high-utility use-case for such. If such is found, then HTTP2 can be revised to include it. This is the approach we've been taking with most of the HTTP2 stuff, since there has been great effort placed on allowing new versions to be deployed in the future.

The mapping of WS onto HTTP2 is fairly direct-- we reserved the MSG_DONE bit specifically for this kind of use-case (i.e. bidirectional, full-duplex, message-based).
The observation made is that there are essentially 3 types of data that need to be preserved one way or another:
1) metadata: data about the data, e.g. text, binary, where it is supposed to be going, etc.
2) payload
3) boundaries between these.

imho, metadata is handled with HEADERS (I'd have preferred it to be called METADATA, but was voted down at the time :) ), payload is handled with DATA frames, and the boundaries are delimited either through the use of HEADERS frames, or via the MSG_DONE or STREAM_DONE bits.
In the presence of extensions, assuming that MSG_DONE is required to signal the end of a message, then HEADERS can be used to signal any boundary desired.

I totally agree that it would be nice to expose the priority of various messages/channels with respect to each other. That is really an issue that is outside the WG's purvue, though.

On Thu, Jan 9, 2014 at 7:54 PM, Yutaka Hirano <[email-masked]<mailto:[email-masked]>> wrote:
+Roberto as an HTTP2 expert.

On Thu, Jan 9, 2014 at 6:53 PM, Tobias Oberstein <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yutaka,

Cheers,
/Tobias

Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von Yutaka Hirano
Gesendet: Donnerstag, 9. Januar 2014 10:37
An: Tobias Oberstein
Cc: Takeshi Yoshino; [email-masked]<mailto:[email-masked]>
Betreff: Re: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

Hi Tobias,

1) Frame Mapping
"""

2) End of WS Frame

3) WS extension

Anyway, some questions:

1) Frame Mapping
"""

2) End of WS Frame

3) WS extension

Thanks!
/Tobias

Hi all,

---

From: Roberto Peon <[email-masked]>
Date: Tue, 14 Jan 2014 12:07:26 -0800

> 1) WebSocket frame boundaries _can_ have semantic meaning in WebSocket

Agreed. And there are none deplyed that we know about where this is a
concern.

> however, non-final WebSocket frame ends cannot be _immediately_ detected.

I'm not sure what you mean here?

>   * is comfortable to implement for implementations that _only_ want to
> implement WS/SPDY, and not native WS at the same time
>
>  * makes things complicated for WS implementations that want to support
> both WS/SPDY _and_ native WS at the same time
>

The complication here is relative. Using the approach proposed in terms of
using MSG_DONE, etc. would make deployment at large sites like Google
substantially easier as large sites typically want to see the semantic
boundaries easily, quickly, and consistently, as there needs to be robust
mechanisms for handling failover, etc. The more layers of interpretation
there are when doing this, the bigger the number of problems.

I'm honestly not worried about the potential increased overhead-- arguably
HTTP2 reduces overhead substantially simply be requiring fewer handshakes
(the connection setup is a non-trivial amount of bytes and latency. That
this was ignored was hugely frustrating to me during the initial
standardization process here in HyBi). Even discounting this, I haven't
actually heard of use-cases where a well-written application sends so many
messages that the bandwidth is saturated. I am for efficiency (had to work
on compression for HTTP2, for instance), but not when it increases
complexity in the more general case.

In terms of total amount of code:
In any layering scheme, we'd need to use a HEADER frame one way or another
because we need to at least announce that we're connecting to a WS endpoint.
In terms of decode, we're essentially talking the following state machine:

if frame.type == HEADERS:
    streams[frame.stream_id] = Stream(frame.headers)
elif frame.type == DATA:
    payload[frame.stream_id] += frame.payload
    if frame.MSG_DONE or frame.STREAM_DONE:
      passMessageToApplication(payload[frame.stream_id])
      del payload[frame.stream_id]
if frame.STREAM_DONE:
  del streams[frame.stream_id]

While the above is pseudocode and leaves out error handling, one of the
interesting things is that it is the same for both HTTP, WS, or any other
protocol layering over HTTP2.

> Pack WebSocket frames _including_ full WS frame header as _payload_ of
> SPDY data frames only - no SPDY header frames at all.
>
>
>
> In the absence of negotiated WebSocket extensions (or when all WS
> extensions in place do not assign semantics to WS frame boundaries),
>
> fragment WebSocket payload at the WS level such that WS frame
> header+payload fits into the payload of SPDY data frames.
>
>
>
> In the latter case, this essentially adds a small SPDY data frame header
> (of fixed length) to WS frames. Easy to implement and efficient on wire.
>
>
>
> The only disadvantage is for implementations that _only_ want to implement
> WS/SPDY and not native WS at the same time.
>

One of the nice things about the current plan as compared to your proposal
is that it allows for generic infrastructure to be built to examine and
handle things for DoS and loadbalancing concerns across any protocol using
HTTP2 as a session layer since all boundaries are clearly demarcated. It
seems like a very nice thing indeed that HTTP, WS, various internal API
things, etc. can all end up using the same infrastructure.

Additionally, what happens if/when someone defines a mapping for HTTP2 onto
something like QUIC, SCTP, TCP-Minion, or perhaps the RTCWeb stack? With
the proposed design where the HTTP2 layer has full visibility into the
semantic boundaries, this mapping needs to be done only once for the HTTP2
session layer and all protocols layered atop it are now able to take
advantage of it (one would need signaling about HOL blocking properties of
streams to the HTTP2 layer in addition, of course). When we hide the
semantic boundaries, this requires work from every implementor, and impedes
adoption either of the new HTTP2 mapping onto the better transport, or
impedes adoption of WS.

I want to see the WS API succeed at scale and continue to do so into the
future, so, my thought is that the advantages in regularity/consistency
(today for DoS and loadbalancing, tomorrow on new transports) outweigh the
relatively small theoretical byte efficiency tradeoff.
As I mentioned earlier, this is the tradeoff that HTTP2 has made for HTTP
at the application layer as well, so even the approach is consistent :)

>
> ==
>
>
>
> Regarding "permessage-priority" with ordering guarantees: should I find
> time and if there is interest, I'll write something up.
>

Yup. The same thing is happening for HTTP (people finding that expressing
priority for resources is useful), btw, from what I'm led to understand.
I'm hopefuly for the day when APIs allow us to easily signal both priority,
and also other important properties like drop-dead-times (get this message
to the other side at most in X seconds from now, else leave it on the
floor), and ordering requirements (e.g. don't care about ordering, care
about ordering, but only to know when something has been dropped, etc.).
The interesting thing about priorities is that it is really only useful
when you're muxing over one connection/session.
-=R

>
> Just my 2cts,
>
> Tobias
>
>
>
>
>
>
>
>
>
> *Von:* Roberto Peon [mailto:[email-masked]]
> *Gesendet:* Dienstag, 14. Januar 2014 19:30
> *An:* Yutaka Hirano
> *Cc:* Tobias Oberstein; Takeshi Yoshino; [email-masked]
>
> In the presence of extensions, assuming that MSG_DONE is required to
> signal the end of a message, then HEADERS can be used to signal any
> boundary desired.
>
>
>
>
>

---

From: Adam Rice <[email-masked]>
Date: Wed, 15 Jan 2014 13:41:57 +0900

>  * has significant wire-level overhead compared to native WS (and compared
If you accept the argument that unencrypted WebSockets are unusable on
heterogeneous networks due to interference from middleboxes, then the byte
overhead is a red-herring. Everything has to be encrypted, and so will get
padded out to the cipher block size anyway.

What is significant is the CPU overhead, which means battery life on mobile
devices and latency everywhere. The WebSocket frame header is trivial to
construct. SPDY HEADERS, not so much.

Adam Rice

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 15 Jan 2014 14:42:37 +0900

>  I'm not sure what you mean here?

In current proposal, we mark only the end of each message (or the end of
control frame) using MSG_DONE. So, until an endpoint sees the next HEADERS
frame, it cannot determine the end of the frame is reached or not. I think
that's what Tobias meant.

---

From: Yutaka Hirano <[email-masked]>
Date: Wed, 15 Jan 2014 14:51:43 +0900

>   del streams[frame.stream_id]

In the proposal in the doc, there are two kind of HEADERS, for handshake
and for WS frame headers.
Then I think the pseudocode will be like this:

# TODO: message injection is not addressed in this code.
if frame.type == HEADERS:
  if frame.stream_id not in streams:
    # stream initialization
    streams[frame.stream_id] = Stream(frame.headers)
  else:
    # WS frame header
    stream = streams[frame.stream_id]
    if stream.current_processing_message is None:
       stream.current_processing_message = Message()
    stream.current_processing_frame = Frame(frame.headers)
elif frame.type == DATA:
  stream = streams[frame.stream_id]
  # How to add payload depends on the WS frame header
  stream.current_processing_message.addPayload(frame.payload,
stream.current_processing_frame)
if frame.MSG_DONE:
  stream = streams[frame.stream_id]
  passMessageToApplication(stream.current_processing_message)
  stream.current_processing_message = None
if frame.STREAM_DONE:
  del stream[frame.stream_id]

Am I missing something?

On Wed, Jan 15, 2014 at 5:07 AM, Roberto Peon <[email-masked]> wrote:

>> The only disadvantage is for implementations that _only_ want to
>> implement WS/SPDY and not native WS at the same time.
>>
>
> Additionally, what happens if/when someone defines a mapping for HTTP2
> onto something like QUIC, SCTP, TCP-Minion, or perhaps the RTCWeb stack?
> With the proposed design where the HTTP2 layer has full visibility into the
> I'm hopefuly for the day when APIs allow us to easily signal both
> priority, and also other important properties like drop-dead-times (get
> this message to the other side at most in X seconds from now, else leave it
> on the floor), and ordering requirements (e.g. don't care about ordering,
> care about ordering, but only to know when something has been dropped,
> etc.).
>> imho, metadata is handled with HEADERS (I'd have preferred it to be
>> called METADATA, but was voted down at the time :) ), payload is handled
>> with DATA frames, and the boundaries are delimited either through the use
>> of HEADERS frames, or via the MSG_DONE or STREAM_DONE bits.
>>

---

From: Yutaka Hirano <[email-masked]>
Date: Wed, 15 Jan 2014 15:29:53 +0900

FYI: I added the framing overhead measurement result at the last of the
document (Memo - Framing overhead section).

Thanks,

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 14 Jan 2014 22:34:20 -0800

>I'm not sure what you mean here?
 
In the WS/SPDY proposal, a single WS frame is transmitted as 1 SPDY HEADER + n SPDY DATA frames.

Since the SPDY HEADER for the WS frame does not contain the WS frame payload length field, the end of the WS frame
can only be detected by

a) MSG_DONE - if it's the last WS frame in the WS message
b) by receiving the _next_ SPDY HEADER frame (which marks the beginning of the next WS frame)

This has possible implications for WS implementations that expose a frame-based API and for WS extensions.

>>The complication here is relative. Using the approach proposed in terms of using MSG_DONE, etc. would make deployment at large sites like Google substantially easier as large sites typically want to see the semantic boundaries easily, quickly, and consistently, as >>there needs to be robust mechanisms for handling failover, etc. The more layers of interpretation there are when doing this, the bigger the number of problems. 

Mmh. The semantic boundary for a WebSocket connection isn't the individual WebSocket message, but the whole connection, since message order might have significance at application level.

Failing over a WebSocket connection in the middle (being it at WS message boundary or not) might break things at app level.

This is different from the HTTP request/response model, where each request and response basically stands on it's own.

>>I'm honestly not worried about the potential increased overhead-- arguably HTTP2 reduces overhead substantially simply be requiring fewer handshakes (the connection setup is a non-trivial amount of bytes and latency. That this was ignored was hugely frustrating >>to me during the initial standardization process here in HyBi). Even discounting this, I haven't actually heard of use-cases where a well-written application sends so many messages that the bandwidth is saturated. I am for efficiency (had to work on compression for >>HTTP2, for instance), but not when it increases complexity in the more general case.

IMHO, shoehorning WS frame headers into SPDY header complicates things.

>>In any layering scheme, we'd need to use a HEADER frame one way or another because we need to at least announce that we're connecting to a WS endpoint.

No, the alternative WS/SPDY proposal uses SPDY HEADER only for the initial WS opening handshake, but not for the subsequent WS messaging traffic.

>>One of the nice things about the current plan as compared to your proposal is that it allows for generic infrastructure to be built to examine and handle things for DoS and loadbalancing concerns across any protocol using HTTP2 as a session layer since all boundaries >>are clearly demarcated. It seems like a very nice thing indeed that HTTP, WS, various internal API things, etc. can all end up using the same infrastructure.
>>Additionally, what happens if/when someone defines a mapping for HTTP2 onto something like QUIC, SCTP, TCP-Minion, or perhaps the RTCWeb stack? With the proposed design where the HTTP2 layer has full visibility into the semantic boundaries, this mapping

As said above, I think the semantic boundary for failover and such is the WS _connection_, not the WS _message_.

And the WS connection boundary is preserved in the alternative proposal (obviously): it is mapped to a dedicated SPDY stream.

That SPDY stream can of course be treated with respect to DoS, LB, etc as any other SDPY stream.

>Yup. The same thing is happening for HTTP (people finding that expressing priority for resources is useful), btw, from what I'm led to understand. 
>I'm hopefuly for the day when APIs allow us to easily signal both priority, and also other important properties like drop-dead-times (get this message to the other side at most in X seconds from now, else leave it on the floor), and ordering requirements (e.g. don't >care about ordering, care about ordering, but only to know when something has been dropped, etc.).
>The interesting thing about priorities is that it is really only useful when you're muxing over one connection/session.

It would be interesting to have a "permessage-priority" extension for WebSocket and transport HTTP request/responses over that single WS connection, but with priority assigned to each individual HTTP request/response.

This would work differently from SPDY where each HTTP request/response is running over a separate ephemeral stream with priority assigned to the stream.

Of course we would then also need a "http" extension for WS wrapping HTTP request/respones - that might reuse the SPDY work done on HEADERS in particular.

/Tobias

-=R

Just my 2cts,
Tobias

 

 

 

 

On Thu, Jan 9, 2014 at 6:53 PM, Tobias Oberstein <[email-masked]> wrote:
Hi Yutaka,

 

 
Cheers,
/Tobias

 
Hi Tobias,
 
1) Frame Mapping
"""
 
2) End of WS Frame
 
3) WS extension
 
On Thu, Jan 9, 2014 at 6:11 PM, Tobias Oberstein <[email-masked]> wrote:
Hi Takeshi,

Anyway, some questions:

1) Frame Mapping
"""

2) End of WS Frame

3) WS extension

Thanks!
/Tobias

Hi all,

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 15 Jan 2014 15:59:51 +0900

On Wed, Jan 15, 2014 at 3:34 PM, Tobias Oberstein <
[email-masked]> wrote:

> >>In any layering scheme, we'd need to use a HEADER frame one way or
> another because we need to at least announce that we're connecting to a WS
> endpoint.
>
> No, the alternative WS/SPDY proposal uses SPDY HEADER only for the initial
> WS opening handshake, but not for the subsequent WS messaging traffic.

I think Roberto meant that we need to have code to parse HEADERS frame
regardless of how layering scheme is. As you say, we'll exchange opening
handshake using HEADERS. I.e. a server implementing your proposal will have
HEADERS parser. So, use of HEADERS itself doesn't add cost.

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 14 Jan 2014 23:00:56 -0800

>>If you accept the argument that unencrypted WebSockets are unusable on heterogeneous networks due to interference from middleboxes, then the byte overhead is a red-herring. Everything has to be encrypted, and so will get padded out to the cipher block size >>anyway.

Yes, I agree with the argument of TLS being a practical necessity. For reasons of network restrictions and also privacy.

Regarding the cipher block padding: yes, if each WS message is sent out immediately, the padding kicks in and probably masks any small differences in framing overhead.

But if the WS messages are sent out in batches, the cipher block padding will only apply to batches of WS messages, and framing overhead might again be relevant.

A JS app library can have buffering of app level messages in queues, and send out WS messages from queue to wire via a timer triggered sender function.

Or a browser could do the equivalent internally: not produce a new TLS segment on each and every call to websocket.send() (from JS), but batch up.

In fact, I don't know how browsers currently do that under the hood.

>>What is significant is the CPU overhead, which means battery life on mobile devices and latency everywhere. The WebSocket frame header is trivial to construct. SPDY HEADERS, not so much.

Exactly.

/Tobias

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 14 Jan 2014 23:07:01 -0800

>I think Roberto meant that we need to have code to parse HEADERS frame regardless of how layering scheme is. As you say, we'll exchange opening handshake using HEADERS. I.e. a server implementing your proposal will have HEADERS parser. So, use of HEADERS >itself doesn't add cost.

Yes, SPDY HEADER parsing code needs to be there in both, but:

The implementation cost for the current WS/SPDY proposal is for WS implementations that want to both support native WS and WS/SPDY:

the WS message data processing code needs to be intermingled with SPDY code.

With the alternative proposal (after the WS opening handshake is finished), the WS code can stay essentially untouched: the bytes just not come from wire anymore, but from SPDY data frame payloads.

/Tobias

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 15 Jan 2014 16:14:51 +0900

On Wed, Jan 15, 2014 at 3:34 PM, Tobias Oberstein <
[email-masked]> wrote:

> >>The complication here is relative. Using the approach proposed in terms
> of using MSG_DONE, etc. would make deployment at large sites like Google
> boundaries easily, quickly, and consistently, as >>there needs to be robust
> Mmh. The semantic boundary for a WebSocket connection isn't the individual
> WebSocket message, but the whole connection, since message order might have
> significance at application level.
>
> Failing over a WebSocket connection in the middle (being it at WS message
> boundary or not) might break things at app level.
>
> This is different from the HTTP request/response model, where each request
> and response basically stands on it's own.

It depends on how the app corresponds transactions to messages. We're
thinking of deploying L7 DoS protectors for WebSocket that are separate
from backends. In such a case, DoS protectors doesn't fully understand
what's going on at app level but we'll teach them how much cost each
message has and let them drop/throttle connection when there's flood based
on that metric.

Complexity of such infrastructure would be reduced if less framing is used,
comparatively.

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 14 Jan 2014 23:29:55 -0800

>>>The complication here is relative. Using the approach proposed in terms of using MSG_DONE, etc. would make deployment at large sites like Google substantially easier as large sites typically want to see the semantic boundaries easily, quickly, and consistently, as >>>there needs to be robust mechanisms for handling failover, etc. The more layers of interpretation there are when doing this, the bigger the number of problems. 

>It depends on how the app corresponds transactions to messages. We're thinking of deploying L7 DoS protectors for WebSocket that are separate from backends. In such a case, DoS protectors doesn't fully understand what's going on at app level but we'll teach >them how much cost each message has and let them drop/throttle connection when there's flood based on that metric.

>Complexity of such infrastructure would be reduced if less framing is used, comparatively.

Not sure if I understand: do you want to throttle

a) individual WebSocket messages wrt to other WS messages on the same (logical) WS connection 

or

b) throttle traffic per WS connection and wrt to other SPDY traffic?

The latter can be done with the alternative proposal also, since each WS connection (with all WS messages for that connection) is running on a dedicated SPDY stream.

So a L7 DoS protection intermediary capable of throttling per SPDY stream would be able to throttle e.g. HTTP/GETs for images versus (individual) WS connections.

What the alternative proposal makes harder would be throttling _individual_ WS messages on a _single_ WS connection.

But since the ordering of WS messages needs to be preserved, throttling a single WS message pretty much amounts to throttling the complete (logical) WS connection.

Probably I just don't know enough about the specific scenarios/requirements you have in mind ..

/Tobias

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 15 Jan 2014 16:41:46 +0900

On Wed, Jan 15, 2014 at 4:07 PM, Tobias Oberstein <
[email-masked]> wrote:

> >>No, the alternative WS/SPDY proposal uses SPDY HEADER only for the
> initial WS opening handshake, but not for the subsequent WS messaging
> traffic.
>
> HEADERS parser. So, use of HEADERS >itself doesn't add cost.
>
> The implementation cost for the current WS/SPDY proposal is for WS
> implementations that want to both support native WS and WS/SPDY:
>
> With the alternative proposal (after the WS opening handshake is
> finished), the WS code can stay essentially untouched: the bytes just not
> come from wire anymore, but from SPDY data frame payloads.
>

Right. Inter-layer coordination complicates things given one has already
implemented RFC6455. I understand your argument about clear layering.

It seems that there're different visions of how future transport for
WebSocket API should be. IIUC, Roberto is trying to make HTTP/2.0 versatile
transport for the web. He's thinking it's costly to carry over RFC6455 to
that future. In Google, as you know, we're deploying SPDY widely and
therefore SPDY is always there. If HTTP/2.0 is success, it'll be true also
for others.

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 15 Jan 2014 08:01:10 -0800

>>On 15 January 2014 04:09, Tobias Oberstein <[email-masked]> wrote:

>If you accept the argument that unencrypted WebSockets are unusable on heterogeneous networks due to interference from middleboxes, then the byte overhead is a red-herring. Everything has to be encrypted, and so will get padded out to the cipher block size >anyway.

I did more readup on this one .. e.g. not all modes require padding (AES-GCM does not) - nevertheless, you are totally right: the overhead of TLS can be substantial.

Here are measurements for Chrome, Firefox and IE11:

http://tavendo.com/blog/post/dissecting-websocket-overhead/

The overhead induced by TCP/IP and TLS in particular can dwarf the overhead of WebSocket itself.

Thank you very much for pointing into this direction .. this is important.

As an immediate consequence, we will introduce message batching into WAMP (a WebSocket subprotocol for RPC+PubSub - https://github.com/tavendo/WAMP/tree/master/spec )

/Tobias

---

From: Joakim Erdfelt <[email-masked]>
Date: Wed, 15 Jan 2014 10:07:53 -0700

One minor niggle from Jetty on this (we are lurking and reading)

Knowing the size of a frame at the start of the frame, traditional
websocket behavior, is desired, as it allows us to fast fail for the 1009
(message too big) use case.
Having no prior knowledge of frame size is undesirable to us.
This is inline with what Tobias is asking for too.

--
Joakim Erdfelt <[email-masked]>
webtide.com <http://www.webtide.com/> - intalio.com/jetty
Expert advice, services and support from from the Jetty & CometD experts
eclipse.org/jetty - cometd.org

On Wed, Jan 15, 2014 at 9:01 AM, Tobias Oberstein <
[email-masked]> wrote:

> padded out to the cipher block size >anyway.
>
> I did more readup on this one .. e.g. not all modes require padding
> (AES-GCM does not) - nevertheless, you are totally right: the overhead of
> TLS can be substantial.
>
> As an immediate consequence, we will introduce message batching into WAMP
> (a WebSocket subprotocol for RPC+PubSub -
> https://github.com/tavendo/WAMP/tree/master/spec )
>
> /Tobias

---

From: Peter Thorson <[email-masked]>
Date: Wed, 15 Jan 2014 21:33:08 -0600

If RFC6455 semantics are to be preserved the only way that it makes sense to do that is in a fully tunneled method such that the resulting stream could be fed to an existing RFC6455 infrastructure. While conceptually simple, as mentioned a number of times in the past threads, this introduces a number of problems including significant overhead and reduced transparency to HTTP 2.0 intermediaries. I don’t see any great benefit in this method.

I also don’t see any benefit in doing a half and half style protocol where RFC6455 frames are encapsulated in HTTP 2.0 header+data frame pairs. This seems like the worst of both worlds. Not enough like RFC6455 to actually re-use existing infrastructure but enough like it to make the messaging component not mesh well with the rest of HTTP 2.0. The alternate method proposed earlier where HTTP 2.0 simply defines its own “ordered bidirectional message stream” semantics independently of RFC6455 either via a specific frame type or via additional flags on the data frame seems to be an obvious choice to me.

HTTP 2.0 natively provides all of the core facilities that RFC6455 does: connection establishment, header flags, control messaging, close messaging, framing, etc. There is no need to redefine any of this in terms of RFC6455 opcodes or frame bits order to exchange messages bidirectionally over the existing connection between an HTTP 2.0 browser and server. Doing so only adds complexity for no real benefit. At best I can see including a method for mapping RFC6455 close codes to RST_STREAM error codes.

Using HTTP 2.0 for this sort of messaging would be less efficient than raw RFC6455 but likely more efficient overall for sites with a healthy mix of HTTP and WebSocket traffic to the same host. It would also solve any issues about unknown frame boundaries, make all messaging traffic a first class HTTP 2.0 citizen and understandable to intermediaries. It would not require HTTP 2.0 only programs to also have an RFC6455 parser. It would remove the need to try and fit any extensions designed for RFC6455 into HTTP 2.0 or restrict RFC6455 extension design to things that could fit into HTTP 2.0. There doesn’t seem to be anything supported by the JavaScript WebSocket API that couldn’t be easily transported using such a scheme.

That said, because of the differences between HTTP 2.0 and RFC6455 WebSockets I would hope to see them coexist in browsers rather than be a replacement. There are a number of cases that users of my WebSocket library have discussed with me where HTTP 2.0 is vast overkill and needlessly complex for what they need and RFC6455 fits the bill perfectly.

On the subject of WS MUX, given the existence of a protocol like HTTP 2.0 with the above messaging feature, based on the experiences of my library users and clients, any use case for a muxed WebSocket-type messaging system would be satisfied by HTTP 2.0.

On Jan 15, 2014, at 1:41, Takeshi Yoshino <[email-masked]> wrote:

> On Wed, Jan 15, 2014 at 4:07 PM, Tobias Oberstein <[email-masked]> wrote:
> Right. Inter-layer coordination complicates things given one has already implemented RFC6455. I understand your argument about clear layering.
> 
> It seems that there're different visions of how future transport for WebSocket API should be. IIUC, Roberto is trying to make HTTP/2.0 versatile transport for the web. He's thinking it's costly to carry over RFC6455 to that future. In Google, as you know, we're deploying SPDY widely and therefore SPDY is always there. If HTTP/2.0 is success, it'll be true also for others.

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 16 Jan 2014 14:13:12 +0900

Peter,

Is the method you prefer "Plan B: Frame by frame mapping" in [1]?
If not, can you provide some pointers?

Thanks,

[1]
https://docs.google.com/a/google.com/document/d/1Dwd23OXidSRA0DupeWujYz2iPyVzvZT6RmEeg4vPY28/edit

On Thu, Jan 16, 2014 at 12:33 PM, Peter Thorson <[email-masked]>wrote:

> If RFC6455 semantics are to be preserved the only way that it makes sense
> to do that is in a fully tunneled method such that the resulting stream
> could be fed to an existing RFC6455 infrastructure. While conceptually
> simple, as mentioned a number of times in the past threads, this introduces
> a number of problems including significant overhead and reduced
> transparency to HTTP 2.0 intermediaries. I don’t see any great benefit in
> this method.
>
> I also don’t see any benefit in doing a half and half style protocol where
> RFC6455 frames are encapsulated in HTTP 2.0 header+data frame pairs. This
> seems like the worst of both worlds. Not enough like RFC6455 to actually
> re-use existing infrastructure but enough like it to make the messaging
> component not mesh well with the rest of HTTP 2.0. The alternate method
> proposed earlier where HTTP 2.0 simply defines its own “ordered
> bidirectional message stream” semantics independently of RFC6455 either via
> a specific frame type or via additional flags on the data frame seems to be
> an obvious choice to me.
>
> HTTP 2.0 natively provides all of the core facilities that RFC6455 does:
> connection establishment, header flags, control messaging, close messaging,
> framing, etc. There is no need to redefine any of this in terms of RFC6455
> opcodes or frame bits order to exchange messages bidirectionally over the
> existing connection between an HTTP 2.0 browser and server. Doing so only
> adds complexity for no real benefit. At best I can see including a method
> for mapping RFC6455 close codes to RST_STREAM error codes.
>
> Using HTTP 2.0 for this sort of messaging would be less efficient than raw
> RFC6455 but likely more efficient overall for sites with a healthy mix of
> HTTP and WebSocket traffic to the same host. It would also solve any issues
> about unknown frame boundaries, make all messaging traffic a first class
> HTTP 2.0 citizen and understandable to intermediaries. It would not require
> HTTP 2.0 only programs to also have an RFC6455 parser. It would remove the
> need to try and fit any extensions designed for RFC6455 into HTTP 2.0 or
> restrict RFC6455 extension design to things that could fit into HTTP 2.0.
> There doesn’t seem to be anything supported by the JavaScript WebSocket API
> that couldn’t be easily transported using such a scheme.
>
> That said, because of the differences between HTTP 2.0 and RFC6455
> WebSockets I would hope to see them coexist in browsers rather than be a
> replacement. There are a number of cases that users of my WebSocket library
> have discussed with me where HTTP 2.0 is vast overkill and needlessly
> complex for what they need and RFC6455 fits the bill perfectly.
>
> On the subject of WS MUX, given the existence of a protocol like HTTP 2.0
> with the above messaging feature, based on the experiences of my library
> users and clients, any use case for a muxed WebSocket-type messaging system
> would be satisfied by HTTP 2.0.
>
>

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 16 Jan 2014 15:05:35 +0900

Hi Joakim,

Thanks for the comment.

> (message too big) use case.

Do you know how effective it is?

On the other hand, the frame sender have more freedom because they don't
have to know the size of the frame in front.
For example, it can construct and send a big WS data frame without minding
a control frame which may appear and be injected afterward.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 16 Jan 2014 15:27:34 +0900

> have to know the size of the frame in front.

My understanding of why messages are split into frames was that this 
would allow to start a message without knowing its length. But if you 
don't know the size of a frame before sending it, then the right 
solution is to make it smaller. Frames are just arbitrary pieces of a 
message.

Regards,   Martin.

---

From: Yutaka Hirano <[email-masked]>
Date: Mon, 20 Jan 2014 16:03:45 +0900

Tobias, let me confirm.

> SPDY data frames only - no SPDY header frames at all.

My understanding is that by suggesting the above one you retracted the
below proposal you made before, is that right?

> Similar for a WS binary message.

Doing like above will allow to preserve the current WS API in HTML5 (which
> needs messages, and needs 2 message types).

Thanks,

---

From: Yutaka Hirano <[email-masked]>
Date: Mon, 20 Jan 2014 19:37:25 +0900

Hi Roberto,

> 3) boundaries between these.

Given that in WebSocket metadata belongs to WS Frame not to WS Message, I'm
wondering if it is better to use MSG_DONE as the boundary between WS Frames.
In addition to that, we can simply map a WS Frame to a HTTP2 HEADERS and
DATAs, but WS Message is fairly complicated (e.g. control message injection
in a data message).
I believe that we should split the WebSocket spec into abstract parts and
concrete parts, define concrete parts for HTTP2 and share abstract parts
between WS and WS/HTTP2.
I think the boundary of them should be WebSocket Frame, i.e. WS/HTTP2
specific framing spec should not know about WS Message.
What do you think?

On Wed, Jan 15, 2014 at 3:30 AM, Roberto Peon <[email-masked]> wrote:

> On Thu, Jan 9, 2014 at 7:54 PM, Yutaka Hirano <[email-masked]>wrote:
>
>>> When you receive a SPDY frame with MSG_DONE, you can recognize that it
>>> is the last SPDY frame in a WebSocket message and hence the last SPDY frame
>>> in a WebSocket frame.
>>>
>>>
>>>
>>> 3) WS extension
>>> Are WS extensions fully supported? In particular, is
>>> "permessage-deflate" supported when running WS/SPDY?
>>>
>>> Are WS extensions fully supported? In particular, is
>>> "permessage-deflate" supported when running WS/SPDY?
>>>
>>> Thanks!
>>> /Tobias
>>>
>>>

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 20 Jan 2014 03:16:17 -0800

Hi Yutaka,

in fact, I completely agree with Peter (http://www.ietf.org/mail-archive/web/hybi/current/msg10310.html) - either have

1) full WebSocket tunneled over SPDY ("SPDY/WS-Tunnel")
=> this is the proposal to transport full WS frames as payload of SPDY data frames describe in my other post

or

2) define a SPDY messaging, independent of WS ("SPDY/Messaging")
=> This is the proposal below (Fri, Jan 10, 2014 at 5:37 PM). Or something in this direction.

The current SPDY/WS proposal is different from both 1) and 2) above, and again I agree with Peter, that this is the least desirable of all.

My order of preference would be:

++1:       SPDY/Messaging
+1:         SPDY/WS-Tunnel
0:            SPDY/WS

/Tobias

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Yutaka Hirano
Gesendet: Montag, 20. Januar 2014 08:04
An: Tobias Oberstein
Cc: Roberto Peon; Takeshi Yoshino; [email-masked]
Betreff: Re: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

Tobias, let me confirm.

Pack WebSocket frames _including_ full WS frame header as _payload_ of SPDY data frames only - no SPDY header frames at all.
My understanding is that by suggesting the above one you retracted the below proposal you made before, is that right?

On Fri, Jan 10, 2014 at 5:37 PM, Tobias Oberstein <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

On Wed, Jan 15, 2014 at 4:09 AM, Tobias Oberstein <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roberto,

==

Just my 2cts,

Tobias

Von: Roberto Peon [mailto:[email-masked]<mailto:[email-masked]>]
Gesendet: Dienstag, 14. Januar 2014 19:30
An: Yutaka Hirano
Cc: Tobias Oberstein; Takeshi Yoshino; [email-masked]<mailto:[email-masked]>

Cheers,
/Tobias

Hi Tobias,

1) Frame Mapping
"""

2) End of WS Frame

3) WS extension

Anyway, some questions:

1) Frame Mapping
"""

2) End of WS Frame

3) WS extension

Thanks!
/Tobias

Hi all,

---

From: Yutaka Hirano <[email-masked]>
Date: Mon, 20 Jan 2014 21:07:08 +0900

Thank you for the explanation, finally I may understand...
Your proposal (SPDY/Messaging) is a brand-new full-duplex messaging
protocol on SPDY and the only constraint is compatibility with the W3C
WebSocket API, right?

On Mon, Jan 20, 2014 at 8:16 PM, Tobias Oberstein <
[email-masked]> wrote:

> Hi Yutaka,
>
>
>
> in fact, I completely agree with Peter (
> http://www.ietf.org/mail-archive/web/hybi/current/msg10310.html) - either
> have
>
>
>
> The current SPDY/WS proposal is different from both 1) and 2) above, and
> again I agree with Peter, that this is the least desirable of all.
>
>
>
> *Gesendet:* Montag, 20. Januar 2014 08:04
> *An:* Tobias Oberstein
> *Cc:* Roberto Peon; Takeshi Yoshino; [email-masked]
>

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 20 Jan 2014 04:17:31 -0800

>Your proposal (SPDY/Messaging) is a brand-new full-duplex messaging protocol on SPDY and the only constraint is compatibility with the W3C WebSocket API, right?

Yes, exactly. 

The only constraint and goal is compatibility with the W3C WebSocket API.

E.g.

// open WebSocket connection
socket = new window.WebSocket("ws://myserver.com");

// open SPDY/Messaging connection
socket = new window.WebSocket("http://myserver.com");

=> "socket" should have identical API in both.

A browser might also automatically fall back to probing the other protocol, if the protocol
requested by the app isn't available:

// first try WS. If that fails, try SPDY/Messaging automatically.
socket = new window.WebSocket("ws://myserver.com");

// first try SPDY/Messaging. If that fails, try WS automatically.
socket = new window.WebSocket("http://myserver.com");

/Tobias

---

From: Peter Thorson <[email-masked]>
Date: Mon, 20 Jan 2014 09:34:28 -0600

Hi all,

Sorry about the delay in clarifying my previous message.

> Your proposal (SPDY/Messaging) is a brand-new full-duplex messaging protocol on SPDY and the only constraint is compatibility with the W3C WebSocket API, right?

That statement describes my point in a nutshell. 

My reasoning and more details/questions:

The goal [roughly] of WebSocket was to provide a protocol for establishing a persistent, ordered, bidirectional messaging channel with minimal framing overhead. This channel’s most important user would be JavaScript applications in web browsers so browser related security concerns and the API there are significant. HTTP 1.1 does not have the functionality required to implement any semblance of these requirements. As such, RFC6455 defines a handshake, framing layer, error handling layer, and guidelines for extensions for a standalone TCP connection that fulfills these requirements.

HTTP 2.0 on the other hand already provides all of the underlying plumbing to provide a persistent, ordered, bidirectional messaging channel. From a browser’s prospective, whether the WebSocket channel that it opens goes through a separate TCP connection, a hybrid “websocket frames encapsulated within HTTP 2.0 frames, or native HTTP 2.0 frames really doesn’t matter as long as HTTP 2.0 is able to match the functionality of the WebSocket browser API.

A simple proposal to support WebSocket API functionality might be something like:

- HTTP 2.0 HEADERS message already provides the functionality necessary to negotiate a given HTTP 2.0 channel as a “WebSocket” channel along with sending subprotocol, cookies, etc.
- An HTTP 2.0 WEBSOCKET frame type could be used to deliver WebSocket messages. You’d need a FIN flag for the message boundaries, frame boundaries would be just standard HTTP 2.0 frames. No need to repackage or reframe or make a distinction between “websocket” frames and HTTP 2.0 frames.
- Depending on how closely we want HTTP 2.0 WebSockets to match RFC6455 WebSockets additional support could be added.. for example, define the WEBSOCKET frame type’s flag bits as follows (full compatibility flag configuration):

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
| FIN |     RFC6455 OPCODE    |RSV1 |RSV2 |RSV3 |
+-----+-----+-----+-----+-----+-----+-----+-----+

This provides the ability to keep RFC6455 opcodes and RSV bits without. Logical WebSocket stream ending would be handled exactly as in RFC6455 by exchanging close frames. This would potentially allow an easier migration for RFC6455 extensions by including the RSV bits.

A more simple frame structure could also be imagined without as much of the RFC6455 compatibility considering the following assumptions: 
- Half of the RFC6455 opcodes are reserved for control messages that so far are entirely provided by HTTP 2.0 natively (ping/pong, stream ending flags, etc).
- So far only two “data” opcodes have been defined.
- RFC6455 extensions have proven to be fairly invasive to base implementations and require a lot of careful thought about how they will interact with each other and the rest of the protocol. Raw WebSocket and HTTP 2.0 may have different enough framing layers that extensions for one may not be directly translatable in the same way the framing isn’t directly translatable. It may be sufficient to adapt the interfaces of popular WebSocket extensions over HTTP 2.0 mechanisms rather than literally try and implement WS extensions in HTTP 2.0. Take for example permessage-deflate extensions. HTTP 2.0 by default will have deflate support and will be maintaining compression contexts for header compression. Multiple different streams within the connection (either HTTP or other WebSockets) might also be interested in compression. Would a more generic compression system that could share state among these connections make sense here rather than individually stored and negotiated compression parameters per logical connection? It certainly would not make sense for raw WebSocket (sans MUX at least).

Example of a potentially simpler WEBSOCKET frame flags (limited compatibility flag configuration):

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
| SFIN| MFIN|UTF8 |     |     |RSV1*|RSV2*|RSV3*|
+-----+-----+-----+-----+-----+-----+-----+-----+

SFIN = stream fin
MFIN = message fin
UTF8 = UTF8 message, validate as such. Alternatively bits 2-4 could represent a “data opcode” similar to the lower 3 bits of RFC6455’s opcode (ie drop the control opcodes).
RSV1-3 could be included as mapped WebSocket extension bits or just used for HTTP 2.0 websocket message bits.

This configuration would also open the option of reusing the straight up DATA frame as that already has the SFIN bit, though the “reserved” #2 bit might be a problem depending on how reserved it actually is. There is certainly enough information in the headers to allow an implementation to know whether a channel is a WebSocket one without a separate message type. I still think a separate message is a good idea because the types of flags for these types of messages will be different and the frame processing logic will be different and i’ve found in my applications at least it is more straight forward to switch on frame type than to keep state about how to interpret a generic “DATA” frame. HTTP 2.0 has a significantly larger range for frame types than RFC6455 did as well.

On Jan 20, 2014, at 6:07, Yutaka Hirano <[email-masked]> wrote:

> On Mon, Jan 20, 2014 at 8:16 PM, Tobias Oberstein <[email-masked]> wrote:
> Hi Yutaka,
> 
>  
> 
> On Fri, Jan 10, 2014 at 5:37 PM, Tobias Oberstein <[email-masked]> wrote:
> 
> On Wed, Jan 15, 2014 at 4:09 AM, Tobias Oberstein <[email-masked]> wrote:
> 
> Hi Roberto,
> 
>  
>

---

From: Peter Thorson <[email-masked]>
Date: Mon, 20 Jan 2014 09:41:19 -0600

In such a setup I would actually prefer that the browser be even more transparent about whether it is using raw WebSocket or HTTP 2.0 “WebSocket”

A WebSocket opened (via ws:// scheme) to the same host/port as the HTTP page itself (or perhaps to any other host/port that already has an HTTP 2.0 connection active) should automatically go over the HTTP 2.0 WebSocket interface if possible and fall back to a new raw WebSocket connection if not. If an application wants to guarantee the use of raw websocket it should use a separate DNS name or port that is only running RFC6455.

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 20 Jan 2014 07:51:34 -0800

Hi Peter

>- HTTP 2.0 HEADERS message already provides the functionality necessary to negotiate a given HTTP 2.0 channel as a "WebSocket" channel along with sending subprotocol, cookies, etc.

Yep.

>- An HTTP 2.0 WEBSOCKET frame type could be used to deliver WebSocket messages. You'd need a FIN flag for the message boundaries, frame boundaries would be just standard HTTP 2.0 frames. No need to repackage or reframe or make a distinction between >"websocket" frames and HTTP 2.0 frames.

Why a separate SPDY frame type? Why not SPDY/DATA frames? After negotiation, the whole SPDY _stream_ will be "messaging" only anyway ..
 
>- Depending on how closely we want HTTP 2.0 WebSockets to match RFC6455 WebSockets additional support could be added.. for example, define the WEBSOCKET frame type's flag bits as follows (full compatibility flag configuration):

>From the goal of W3C WebSocket API only compatibility, the only other information (besides message boundaries) needed in SPDY/DATA frames would be the payload type: UTF8 vs binary.

So the minimum appears to be 2 bits in SPDY/DATA frame headers:

1 bit for MSG_DONE on the last SPDY/DATA frame and
1 bit for MSG_TYPE (UTF8/binary) on the first SPDY/DATA frame that starts a new msg

Am I missing something?

/Tobias

---

From: Peter Thorson <[email-masked]>
Date: Mon, 20 Jan 2014 10:16:17 -0600

> 1 bit for MSG_TYPE (UTF8/binary) on the first SPDY/DATA frame that starts a new msg

Using straight up DATA frames would certainly be an option. I suggest a separate frame type because I think the types of flags you would set for generic requests (like the HTTP 1.1 requests over HTTP 2.0 transport) would be different than the types you would set for the short websocket like messages. Take the UTF8/binary flag (or the RFC6455 opcode in the more general case) for example, does that make sense for a request for an image?

You could argue that you could reinterpret the flags in the DATA frame based on whether or not you have negotiated websocket mode but this seems ripe for confusion and exactly the point of having a frame type. A frame type lets you define what flags mean for that frame type and what the rules for the processing of that frame type would be. It also simplifies implementation logic that might want to logically switch processing branches on frame type.

------
Re: minimum bits

I definitely agree that as written today only message done, stream done, and utf8/binary are necessary. Stream done is present already in the DATA frame type. This does seem to ignore the fact that RFC6455 defines 8 data message types though and might limit compatibility between the two in the future. That said, I am not really sure yet whether that matters. On one hand, text and binary covers quite a few cases and I can’t really think of a good use for more data types visible at the application/WS API level since applications are free via subprotocols/convention to define whatever message types they want. On the other hand, “because I can’t think of a good use case” doesn’t seem like a strong argument.

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 20 Jan 2014 09:35:58 -0800

> Using straight up DATA frames would certainly be an option. I suggest a
> separate frame type because I think the types of flags you would set for
> generic requests (like the HTTP 1.1 requests over HTTP 2.0 transport) would
> be different than the types you would set for the short websocket like
> messages. Take the UTF8/binary flag (or the RFC6455 opcode in the more
> general case) for example, does that make sense for a request for an image?

I agree, MSG_TYPE bit would probably not be useful in general.

> 
> You could argue that you could reinterpret the flags in the DATA frame based
> on whether or not you have negotiated websocket mode but this seems ripe
> for confusion and exactly the point of having a frame type. A frame type lets
> you define what flags mean for that frame type and what the rules for the
> processing of that frame type would be. It also simplifies implementation
> logic that might want to logically switch processing branches on frame type.

However, an implementation would probably want to remember if a SPDY stream ID 
is SPDY/Messaging or not, if just to check that all frames on that stream conform to
SPDY/Messaging requirements: either frame opcode or MSG_TYPE flag, and payload
conformance.

Another consideration are intermediaries: do they want simplified handling (all SPDY/DATA
frames handled alike) or specific handling: SPDY/MESSAGE frame differently.

> 
> ------
> Re: minimum bits
> 
> I definitely agree that as written today only message done, stream done, and
> utf8/binary are necessary. Stream done is present already in the DATA frame
> type. This does seem to ignore the fact that RFC6455 defines 8 data message
> types though and might limit compatibility between the two in the future.

Yep, that's the idea. Ignore other WS opcodes, since those are not exposed in the W3C API
anyway, and compatibility with the latter only was the supposed goal.

There is 1 more API thing: W3C API lets me close a WS with "code" and "reason".

How do would this be mapped?

> That said, I am not really sure yet whether that matters. On one hand, text
> and binary covers quite a few cases and I can't really think of a good use for
> more data types visible at the application/WS API level since applications are
> free via subprotocols/convention to define whatever message types they
> want. On the other hand, "because I can't think of a good use case" doesn't
> seem like a strong argument.

Why not? I think thats a good argument in fact;) If we can't come up with a use case (and
I cannot imagine one also), then why pre-plan for a yet-to-be-imagined chimera?

/Tobias

---

From: Peter Thorson <[email-masked]>
Date: Mon, 20 Jan 2014 11:52:50 -0600

> How do would this be mapped?

I’d probably map it exactly the way it is now in RFC6455. The payload of an HTTP 2.0 frame with stream fin bit set would be the close code + reason.

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 23 Jan 2014 20:16:06 +0900

Thanks for comments and sorry for the late response.

I now agree with your opinion that having both SPDY frame and WS frame is
redundant.
I would like extensions and having RSVs seems a good idea.
As a result, I think it is OK not to support extensions that works on
individual WS frames not WS messages. (i.e. We should support
permessage-deflate.)

- An HTTP 2.0 WEBSOCKET frame type could be used to deliver WebSocket
> messages. You’d need a FIN flag for the message boundaries, frame
> boundaries would be just standard HTTP 2.0 frames. No need to repackage or
> reframe or make a distinction between “websocket” frames and HTTP 2.0
> frames.
> - Depending on how closely we want HTTP 2.0 WebSockets to match RFC6455
> WebSockets additional support could be added.. for example, define the
> WEBSOCKET frame type’s flag bits as follows (full compatibility flag
> configuration):

I don't think it is a good idea, for various reasons.
- Using many flags field reduces extensiveness of the spec (there are only
8 bits).
- Using many flags and adding a WebSocket-specific frame type will not make
httpbis people happy.
- Robustness against SPDY data reframing is important but this framing plan
doesn't have the property.

> 1 bit for MSG_TYPE (UTF8/binary) on the first SPDY/DATA frame that starts

Hmm, then, I think it is good to have
- MSG_DONE in flags for each frame
- MSG_TYPE at the head of a message
- RSVs at the head of a message
.

By the way, I still think it is preferable to decouple metadata from
payload.
Is it acceptable for you to represent a WS data Message by HEADERS + DATAs?
Specifically,
- A WebSocket data message is mapped to a HEADERS frame and multiple DATA
frames.
 - The last frame in a message turns MSG_DONE flag on.
 - The HEADERS frame consists of several headers
  - opcode
  - rsv1
  - rsv2
  - rsv3
- A WebSocket CLOSE message is mapped to a HEADERS frame.
 - The HEADERS frame consists of several headers
  - opcode
  - code
  - reason
 - The HEADERS frame turns END_STREAM on
- A WebSocket PING message is mapped to SPDY PING message
- A WebSocket PONG message is mapped to SPDY PONG message

Thanks,

On Tue, Jan 21, 2014 at 2:52 AM, Peter Thorson <[email-masked]>wrote:

> I’d probably map it exactly the way it is now in RFC6455. The payload of
> an HTTP 2.0 frame with stream fin bit set would be the close code + reason.

---

From: Peter Thorson <[email-masked]>
Date: Sat, 25 Jan 2014 10:24:09 -0600

Critical first question here: Do we have the cooperation of the HTTP 2.0 working group or is the WS over HTTP 2.0 effort something being done unilaterally by the WebSocket working group?

If we are working unilaterally I think the best option is to tunnel raw RFC6455 over a standard HTTP 2.0 data channel and leave it at that. By doing this..
- We retain full control over the standard and protocol and only have to deal with a single protocol when considering future versions, extensions, and other errata fixes.
- We can re-use existing RFC6455 parsing code. Such code is readily available in libraries and already present in many pieces of software that will likely implement HTTP 2.0.
- Tunneling over HTTP 2.0 is more efficient in terms of latency and byte overhead than proposals that try and use HTTP 2.0 framing without cooperation from the HTTP 2.0 standard itself.
- Tunneling makes it fairly easy for intermediaries to be built that package or extract a WebSocket stream from the HTTP 2.0 stream and route it elsewhere. Other sorts of intermediaries are no more difficult to construct than they are today where one must be able to read both HTTP 1.1 and RFC6455.

The only reason I see to do something else would be if we can reduce complexity and improve performance. The HTTP 2.0 spec has goals stated as: "HTTP/2.0 enables a more efficient use of network resources and a reduced perception of latency.". Any proposal for WS over HTTP 2.0 that makes things slower doesn't make sense. HTTP 2.0's single TCP connection introduces some improvements but its internal mechanisms (framing, flow control, header compression, etc) introduce significant (as compared to RFC6455) additional processing, latency, and framing overhead.

Compared to a separate HTTP and WS connection, the performance of tunneling WS over HTTP likely to be better for certain things (initial startup time, TCP packet coalescing) but worse at others (message latency, message overhead after HTTP resources are done loading). Any proposal for more direct framing needs to improve on the performance of tunneling to justify the complexity of maintaining two separate specs and code paths.

I believe the proposal that uses a HEADERS frame + DATA frames is worse than just tunneling raw RFC6455. A headers frame alone is 12 bytes not including the payload. Assume we leave out headers with default values. Assume we get the 88% compression ratio Google saw in its tests of full HTTP header compression. Even then we are talking 15+ bytes on the wire to send 7 bits of data, of which 4-6 are "reserved for future use". Add another 8 bytes per data frame. We are talking invoking string header processing systems and the fixed costs of spinning up the header compression engine and enforcing its strict ordering guarantees for 1-2 headers on every message. This is nearly a full blown HTTP request.

My initial proposal that uses a dedicated WEBSOCKET frame type was specifically set up to improve on the performance of the tunneling strategy as an ordered bidirectional messaging channel while maintaining 100% compatibility with all of the extensibility built into RFC6455. It does that by making full use of the extensibility features of HTTP 2.0 itself. I do not think that using all of the flags for this type reduces the extensibility of the spec because it matches RFC6455 exactly which itself leaves half of those bits "reserved for future use".

It may *look* like there are no more flags available for future use, but in reality most are still reserved for future use just in an order that is compatible with RFC6455. The use of a WebSocket specific HTTP 2.0 frame type means that using all of the flags here doesn't affect the extensibility of the other types of frames used for HTTP data and the separate processing rules are cleanly delineated.

If we are willing to break perfect RFC6455 compatibility we should get rid of the opcode as well. This wouldn't change the wire overhead but would get rid of more redundant logic, free up more flag bits, and make the whole thing more cohesive with the rest of HTTP 2.0. We'd be giving up the ability to transparently support extensions and future protocol versions that define new opcodes (we could still deploy the saved bits explicitly as needed to support them). It would allow using regular DATA frames as well (though I still think a dedicated messaging frame type is beneficial).

Regarding robustness against reframing: There is nothing that would prevent dedicated WEBSOCKET frames from being split or coalesced. The intermediary would just need to understand whatever mechanism is used to determine message boundaries (either opcode or MSG_DONE bit). This is identical to the methods of reframing regular DATA frames.

On Jan 23, 2014, at 5:16, Yutaka Hirano <[email-masked]> wrote:

> I now agree with your opinion that having both SPDY frame and WS frame is redundant.
> As a result, I think it is OK not to support extensions that works on individual WS frames not WS messages. (i.e. We should support permessage-deflate.)
> 
> - Using many flags field reduces extensiveness of the spec (there are only 8 bits).
> - Using many flags and adding a WebSocket-specific frame type will not make httpbis people happy.
> - Robustness against SPDY data reframing is important but this framing plan doesn't have the property.
> 
> By the way, I still think it is preferable to decouple metadata from payload.
> - A WebSocket data message is mapped to a HEADERS frame and multiple DATA frames.
> On Tue, Jan 21, 2014 at 2:52 AM, Peter Thorson <[email-masked]> wrote:
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 27 Jan 2014 16:21:19 +0900

On Sun, Jan 26, 2014 at 1:24 AM, Peter Thorson <[email-masked]>wrote:

> Critical first question here: Do we have the cooperation of the HTTP 2.0
> working group or is the WS over HTTP 2.0 effort something being done
> unilaterally by the WebSocket working group?
>

We want to make HTTP/2.0 good enough for transporting WebSocket API
traffic. MSG_DONE was proposed by Roberto in response to our discussion and
we also want to provide him and httpbis how it can success based on our
experience from RFC 6455 standardization/implementation/deployment.

If it turns out the best things to do is leaving HTTP/2.0 untouched and
layer RFC 6455 onto HTTP/2.0 streams, we can choose it.

The question is what's the best layering. Whether we work with httpbis or
not depends on that question.

---

From: Yutaka Hirano <[email-masked]>
Date: Tue, 28 Jan 2014 20:52:41 +0900

> unilaterally by the WebSocket working group?

If we truly need, we should not hesitate to propose introducing something
to the HTTP 2.0 spec.

My initial proposal that uses a dedicated WEBSOCKET frame type was
> specifically set up to improve on the performance of the tunneling strategy
> as an ordered bidirectional messaging channel while maintaining 100%
> compatibility with all of the extensibility built into RFC6455.

Regarding robustness against reframing: There is nothing that would prevent
> dedicated WEBSOCKET frames from being split or coalesced. The intermediary
> would just need to understand whatever mechanism is used to determine
> message boundaries (either opcode or MSG_DONE bit). This is identical to
> the methods of reframing regular DATA frames.

Sorry, I'm still not sure.
When we are saying "maintaining 100% compatibility with all of the
extensibility built into RFC6455", we should care about the case WS frames
have semantic meanings, as Tobias rightly pointed out. Since the proposal
maps one WS Frame to one HTTP2.0 Frame, HTTP2.0 reframing incurs WS
reframing that can change semantics.

Or, flags except FIN are shared among all frames in a WS Message? If so, it
makes sense.

 I believe the proposal that uses a HEADERS frame + DATA frames is worse
> than just tunneling raw RFC6455. A headers frame alone is 12 bytes not
> including the payload. Assume we leave out headers with default values.
> Assume we get the 88% compression ratio Google saw in its tests of full
> HTTP header compression. Even then we are talking 15+ bytes on the wire to
> send 7 bits of data, of which 4-6 are "reserved for future use". Add
> another 8 bytes per data frame. We are talking invoking string header
> processing systems and the fixed costs of spinning up the header
> compression engine and enforcing its strict ordering guarantees for 1-2
> headers on every message. This is nearly a full blown HTTP request.

The proposal is mapping one WS Message to one HEADERS + multiple DATAs.
For large messages, it can achieve less overhead than WS-TUNNEL at the cost
of some RFC6455 compatibility.

Thanks,

On Sun, Jan 26, 2014 at 1:24 AM, Peter Thorson <[email-masked]>wrote:

> If we are working unilaterally I think the best option is to tunnel raw
> RFC6455 over a standard HTTP 2.0 data channel and leave it at that. By
> doing this..
> - We retain full control over the standard and protocol and only have to
> deal with a single protocol when considering future versions, extensions,
> and other errata fixes.
> - We can re-use existing RFC6455 parsing code. Such code is readily
> available in libraries and already present in many pieces of software that
> will likely implement HTTP 2.0.
> - Tunneling over HTTP 2.0 is more efficient in terms of latency and byte
> overhead than proposals that try and use HTTP 2.0 framing without
> cooperation from the HTTP 2.0 standard itself.
> - Tunneling makes it fairly easy for intermediaries to be built that
> package or extract a WebSocket stream from the HTTP 2.0 stream and route it
> elsewhere. Other sorts of intermediaries are no more difficult to construct
> than they are today where one must be able to read both HTTP 1.1 and
> RFC6455.
>
> The only reason I see to do something else would be if we can reduce
> complexity and improve performance. The HTTP 2.0 spec has goals stated as:
> "HTTP/2.0 enables a more efficient use of network resources and a reduced
> perception of latency.". Any proposal for WS over HTTP 2.0 that makes
> things slower doesn't make sense. HTTP 2.0's single TCP connection
> introduces some improvements but its internal mechanisms (framing, flow
> control, header compression, etc) introduce significant (as compared to
> RFC6455) additional processing, latency, and framing overhead.
>
> Compared to a separate HTTP and WS connection, the performance of
> tunneling WS over HTTP likely to be better for certain things (initial
> startup time, TCP packet coalescing) but worse at others (message latency,
> message overhead after HTTP resources are done loading). Any proposal for
> more direct framing needs to improve on the performance of tunneling to
> justify the complexity of maintaining two separate specs and code paths.
>
> I believe the proposal that uses a HEADERS frame + DATA frames is worse
> than just tunneling raw RFC6455. A headers frame alone is 12 bytes not
> including the payload. Assume we leave out headers with default values.
> Assume we get the 88% compression ratio Google saw in its tests of full
> HTTP header compression. Even then we are talking 15+ bytes on the wire to
> send 7 bits of data, of which 4-6 are "reserved for future use". Add
> another 8 bytes per data frame. We are talking invoking string header
> processing systems and the fixed costs of spinning up the header
> compression engine and enforcing its strict ordering guarantees for 1-2
> headers on every message. This is nearly a full blown HTTP request.
>
> My initial proposal that uses a dedicated WEBSOCKET frame type was
> specifically set up to improve on the performance of the tunneling strategy
> as an ordered bidirectional messaging channel while maintaining 100%
> compatibility with all of the extensibility built into RFC6455. It does
> that by making full use of the extensibility features of HTTP 2.0 itself. I
> do not think that using all of the flags for this type reduces the
> extensibility of the spec because it matches RFC6455 exactly which itself
> leaves half of those bits "reserved for future use".
>
> It may *look* like there are no more flags available for future use, but
> in reality most are still reserved for future use just in an order that is
> compatible with RFC6455. The use of a WebSocket specific HTTP 2.0 frame
> type means that using all of the flags here doesn't affect the
> extensibility of the other types of frames used for HTTP data and the
> separate processing rules are cleanly delineated.
>
> If we are willing to break perfect RFC6455 compatibility we should get rid
> of the opcode as well. This wouldn't change the wire overhead but would get
> rid of more redundant logic, free up more flag bits, and make the whole
> thing more cohesive with the rest of HTTP 2.0. We'd be giving up the
> ability to transparently support extensions and future protocol versions
> that define new opcodes (we could still deploy the saved bits explicitly as
> needed to support them). It would allow using regular DATA frames as well
> (though I still think a dedicated messaging frame type is beneficial).
>
> Regarding robustness against reframing: There is nothing that would
> prevent dedicated WEBSOCKET frames from being split or coalesced. The
> intermediary would just need to understand whatever mechanism is used to
> determine message boundaries (either opcode or MSG_DONE bit). This is
> identical to the methods of reframing regular DATA frames.
>

---

From: Yutaka Hirano <[email-masked]>
Date: Wed, 29 Jan 2014 22:10:17 +0900

Hi all,

I have updated the draft. The new URL is:
https://docs.google.com/a/google.com/document/d/10dKnaojn_d5xkxOanUsdCsRo4nAKfNodmWArWYDAClg/edit#

I added framing proposals proposed in this thread. Please see
"Bi-directional Communication" section.
Correct me if I misunderstand something.
And, other comments, especially for the opening handshake, will be
appreciated.

Thanks,

On Tue, Jan 28, 2014 at 8:52 PM, Yutaka Hirano <[email-masked]> wrote:

> Or, flags except FIN are shared among all frames in a WS Message? If so,
> it makes sense.
>
> For large messages, it can achieve less overhead than WS-TUNNEL at the
> cost of some RFC6455 compatibility.
>
> Thanks,
>
>
>
>> If we are willing to break perfect RFC6455 compatibility we should get
>> rid of the opcode as well. This wouldn't change the wire overhead but would
>> get rid of more redundant logic, free up more flag bits, and make the whole

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 29 Jan 2014 05:49:29 -0800

>- Tunneling makes it fairly easy for intermediaries to be built that package or extract a WebSocket stream from the HTTP 2.0 stream and route it elsewhere. Other sorts of intermediaries are no more…

Those are all good reasons, and I agree, tunneling of full RFC6455 over HTTP2/DATA frame payloads seems the most desirable option overall to me also.

/Tobias

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 29 Jan 2014 05:56:07 -0800

>For large messages, it can achieve less overhead than WS-TUNNEL at the cost of some RFC6455 compatibility.

How can it achieve less overhead?

A SPDY HEADER with information from first WS frame seems to be always bigger than a SPDY DATA header (8 octets) + WS frame header.

The only situation I can think of: a large, _fragmented_ WS message is reframed into a SPDY HEADER+DATAs sequence.

Effectively, you do away with the individual WS frame information. And this exactly breaks full RFC6455 compatibility.

/Tobias

---

From: Roberto Peon <[email-masked]>
Date: Wed, 29 Jan 2014 15:40:19 -0800

I don't find the frame-size arguments very compelling since I haven't seen
or met anyone with a substantial deployment who cares significantly about
the overhead difference given packet, TLS, etc. overheads.
There is no deployment that we know about that uses frame-based
extensibility- we can (and should) remove it from the standard since it
hasn't proven to be interesting.
I'm not sure I agree with your statement that libraries supporting HTTP/2
will include necessarily also have WS framing. It seems unlikely to me-- I
know of at least one large deployment where this isn't at all true.

The HTTP/2 standard has (or shortly will have, as soon as the pull request
goes in) all support necessary to handle any stream-of-message protocol
given support of END_MESSAGE.
I'd strongly prefer that we map WS to those primitives so it, and any other
stream-of-message protocols can be handled using loadbalancer/routing
infrastructure which is and can remain protocol agnostic.

-=R

On Wed, Jan 29, 2014 at 5:56 AM, Tobias Oberstein <
[email-masked]> wrote:

> A SPDY HEADER with information from first WS frame seems to be always
> bigger than a SPDY DATA header (8 octets) + WS frame header.
>
> The only situation I can think of: a large, _fragmented_ WS message is
> reframed into a SPDY HEADER+DATAs sequence.
>
> Effectively, you do away with the individual WS frame information. And
> this exactly breaks full RFC6455 compatibility.
>
> /Tobias

---

From: Peter Thorson <[email-masked]>
Date: Wed, 29 Jan 2014 22:45:12 -0600

On Jan 29, 2014, at 17:40, Roberto Peon <[email-masked]> wrote:

> I don't find the frame-size arguments very compelling since I haven't seen or met anyone with a substantial deployment who cares significantly about the overhead difference given packet, TLS, etc. overheads.

In general I agree, but given that one of the primary goals of HTTP/2 is to improve performance by using compression and multiplexing to more efficiently use fixed TCP and TLS overhead it would be a shame to throw away any of those gains by introducing significant new unnecessary and incompressible framing.

> There is no deployment that we know about that uses frame-based extensibility- we can (and should) remove it from the standard since it hasn't proven to be interesting.

I have no problem with this.

> I'm not sure I agree with your statement that libraries supporting HTTP/2 will include necessarily also have WS framing. It seems unlikely to me-- I know of at least one large deployment where this isn't at all true.

Libraries, not necessarily. Programs (in particular, browsers) probably, unless they never supported WebSocket at all.

> The HTTP/2 standard has (or shortly will have, as soon as the pull request goes in) all support necessary to handle any stream-of-message protocol given support of END_MESSAGE.
> I'd strongly prefer that we map WS to those primitives so it, and any other stream-of-message protocols can be handled using loadbalancer/routing infrastructure which is and can remain protocol agnostic.

An official END_MESSAGE flag in the HTTP DATA frame spec sounds good for this purpose. A message delimiter alone is insufficient to allow WebSocket traffic as it exists today however. At minimum an additional type bit would be needed to determine binary vs UTF8 and ideally a compressed vs not bit. These do not strike me as universally useful for HTTP/2 data frames as for HTTP requests this type of information has many more values and is typically carried in HTTP headers. Does it make sense to have a single DATA frame type given that the flag needs for message type frames are different from those of full HTTP request frames?

> -=R
> 
> 
> On Wed, Jan 29, 2014 at 5:56 AM, Tobias Oberstein <[email-masked]> wrote:

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 30 Jan 2014 17:58:53 +0900

> reframed into a SPDY HEADER+DATAs sequence.

Yes. A WebSocket message is mapped to one HEADERS + multiple DATAs, even if
it consists of multiple WebSocket frames.

> this exactly breaks full RFC6455 compatibility.

Yes. Most of WebSocket headers are shared among all frames in a WebSocket
message.

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 30 Jan 2014 03:54:56 -0800

>There is no deployment that we know about that uses frame-based extensibility- we can (and should) remove it from the standard since it hasn't proven to be interesting.

There is a draft for a WebSocket extension ("permessage-priority") being currently developed that makes use of this and we will start an experimental implementation in Autobahn. It _is_ interesting.

In any case, the ability for framing, and the ability for WS extensions to interleave WS messages is part of RFC6455.

Why remove something from RFC6455 just to fit the limited capabilities that SPDY offers?

>I'm not sure I agree with your statement that libraries supporting HTTP/2 will include necessarily also have WS framing. It seems unlikely to me-- I know of at least one large deployment where this…

I'd put it like this: any networking library that wants to support "messaging" on the Web will need to support native WebSocket, plus optionally any SPDY-based messaging.

Since, WebSocket is deployed _today_ and HTTP2 won't be everywhere anytime soon.

E.g. HTTP/2 support on Windows seems to be coming only on Windows 8+ (since they have HTTP in-kernel). So native WebSocket is the only messaging that works on any IE version on Windows <8.

>I'd strongly prefer that we map WS to those primitives so it, and any other stream-of-message protocols can be handled using loadbalancer/routing infrastructure which is and can remain protocol agno…

That's fine, let's just not call it WebSocket-over-SPDY then;)

Seriously: _what_ is the goal of this effort?

/Tobias

-=R

/Tobias

---

From: Yutaka Hirano <[email-masked]>
Date: Fri, 31 Jan 2014 19:40:55 +0900

> Seriously: _what_ is the goal of this effort?

My motivation is, specifying a multiplexed bidirectional message protocol
conforming to the W3C WebSocket API on HTTP/2.0.

 - The W3C WebSocket API
 - Multiplexing
is mandatory for me.
Since It is built on HTTP/2.0, I prefer strongly the following:
 - A mechanism that enables intermediaries to transfer WS over HTTP/2.0
without fully understanding WS over HTTP/2.0.

The remaining, though they are preferable, are not mandatory for me.
 - RFC6455 conformance
 - small amount of bandwidth efficiency
 - the spec cleanness
 - less-invasiveness

Note: It does not mean I can't accept WS-TUNNEL.

Tobias, Roberto, Peter, can you share your priority?

On Thu, Jan 30, 2014 at 8:54 PM, Tobias Oberstein <
[email-masked]> wrote:

> >I don't find the frame-size arguments very compelling since I haven't
> seen or met anyone with a substantial deployment who cares significantly
> about the overhead difference given packet, TLS, etc. overheads.
> There is a draft for a WebSocket extension ("permessage-priority") being
> currently developed that makes use of this and we will start an
> experimental implementation in Autobahn. It _is_ interesting.
>
> In any case, the ability for framing, and the ability for WS extensions to
> interleave WS messages is part of RFC6455.
>
> I'd put it like this: any networking library that wants to support
> "messaging" on the Web will need to support native WebSocket, plus
> optionally any SPDY-based messaging.
>
> E.g. HTTP/2 support on Windows seems to be coming only on Windows 8+
> (since they have HTTP in-kernel). So native WebSocket is the only messaging
> that works on any IE version on Windows <8.
>
> >The HTTP/2 standard has (or shortly will have, as soon as the pull
> request goes in) all support necessary to handle any stream-of-message
> protocol given support of END_MESSAGE.
> >I'd strongly prefer that we map WS to those primitives so it, and any
> other stream-of-message protocols can be handled using loadbalancer/routing

---

From: Tobias Oberstein <[email-masked]>
Date: Fri, 31 Jan 2014 04:13:48 -0800

Hello Yutaka,

my priorities:

1. allows to provide W3C WebSocket API
2. no "80%-WebSocket-protocol-compatible" design (either compatible with full RFC6455 incl. any extensions or outright independent of WS)
3. does not put servers that provide both native WS and SPDY (but not any SPDY/WS) on same origin at a disadvantage
4. minimizes code coupling between WS and SPDY within implementations

/Tobias

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Yutaka Hirano
Gesendet: Freitag, 31. Januar 2014 11:41
An: Tobias Oberstein
Cc: Roberto Peon; Peter Thorson; [email-masked]
Betreff: Re: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

Seriously: _what_ is the goal of this effort?
My motivation is, specifying a multiplexed bidirectional message protocol conforming to the W3C WebSocket API on HTTP/2.0.

 - The W3C WebSocket API
 - Multiplexing
is mandatory for me.
Since It is built on HTTP/2.0, I prefer strongly the following:
 - A mechanism that enables intermediaries to transfer WS over HTTP/2.0 without fully understanding WS over HTTP/2.0.

/Tobias

-=R

/Tobias