binary streaming over QUIC? (Websockets)

[Van Catha]

I read that there is no current plans to support Websockets in HTTP2 and that carries over to QUIC as QUIC uses HTTP2 for web.

Being able to stream data from client to server, server to client in realtime and without the overhead of http is critical to applications like games and real time apps.

While I can say that websockets is not designed that great, and it took them a while to get things decently right; the critical feature that websockets enables is being able to transmit binary data and the negotiable compression makes JSON a perfectly valid transport protocol.

If Websockets is not planned for HTTP2 and QUIC wont include it, is there any plans to support some kind of binary streaming?
 

[Ryan Hamilton]

The QUIC transport protocol supports bidi stream without HTTP overhead. So if you want to run your own application protocol on top of QUIC, that should work just fine. If you want to do HTTP over QUIC then, as you noticed, you're bound by whatever HTTP/2 requires.

On Tue, Sep 27, 2016 at 3:44 PM, Van Catha <van...@gmail.com> wrote:

I read that there is no current plans to support Websockets in HTTP2 and that carries over to QUIC as QUIC uses HTTP2 for web.

Being able to stream data from client to server without the overhead of http is critical to applications like games and real time apps.

While I can say that websockets is not designed that great, and it took them a while to get things decently right; the critical feature that websockets enables is being able to transmit binary data between client and server.

If Websockets is not planned for HTTP2 and QUIC wont include it, is there any plans to support some kind of binary streaming?
 

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Van Catha]

I could not edit the title to specify in browser. I am aware the HTTP2 part of QUIC is just for the browser and a QUIC client can be outside of chromium.

My specific question is if any plans or discussions for in browser support are in the works.

Without anything modern to stream binary data between a browser and a server; it seems we have taken a step forward while simultaneously stepping backwards.

On Tuesday, September 27, 2016 at 8:36:58 PM UTC-4, r...@chromium.org wrote:

The QUIC transport protocol supports bidi stream without HTTP overhead. So if you want to run your own application protocol on top of QUIC, that should work just fine. If you want to do HTTP over QUIC then, as you noticed, you're bound by whatever HTTP/2 requires.

On Tue, Sep 27, 2016 at 3:44 PM, Van Catha <van...@gmail.com> wrote:

I read that there is no current plans to support Websockets in HTTP2 and that carries over to QUIC as QUIC uses HTTP2 for web.

Being able to stream data from client to server without the overhead of http is critical to applications like games and real time apps.

While I can say that websockets is not designed that great, and it took them a while to get things decently right; the critical feature that websockets enables is being able to transmit binary data between client and server.

If Websockets is not planned for HTTP2 and QUIC wont include it, is there any plans to support some kind of binary streaming?
 

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.

[Patrick McManus]

On Tue, Sep 27, 2016 at 10:07 PM, Van Catha <van...@gmail.com> wrote:

My specific question is if any plans or discussions about it are in the works.

Since Ryan said this is about HTTP/2 rather than google's plans, I'll put on my IETF hat:

The IETF has casually discussed a websockets to H2 binding in the past - and, to generalize, while most find it sensible nobody has found the benefit of doing so enough to prioritize the work of making a h2-websocket specification over other work. I think that is because of the way H2 currently works on TCP the benefits are primarily 'soft' benefits (centralizing on one stack, etc..). Van, I would encourage you to bring forward a draft - with the quic work about to be chartered now is a good time and the benefits may be greater now.

I say this mostly because of the deployability of quic, as compared to TCP evolution. I can imagine a number of scenarios where h2-websockets-quic is considerably better than h1-websockets-tcp in practice so you might find more interested parties that want to leverage that (and help) at this time.

-Patrick

[Van Catha]

So I took up this encouragement and wrote a draft for it https://github.com/vans163/websocket2-drafts/blob/master/websocket2-over-http2.txt.

There is a pressing concern where the draft relies on HTTP/2 transport protocol for the stream management.  QUIC has its own stream management.  Also the proposed websocket2 implementation is its own thing as well.

This leads me question if 3 drafts are needed?  Draft #1 WebSocket2, Draft #2 WebSocket2 over HTTP/2, Draft #3 WebSocket2 over QUIC.

Any chance to get a peer review of this draft? It is only 8 pages.

Also if this checks out, what would be the next step in the process?

[Daniel Stenberg]

On Thu, 29 Sep 2016, Van Catha wrote:

> So I took up this encouragement and wrote a draft for it
> https://github.com/vans163/websocket2-drafts/blob/master/websocket2-over-http2.txt.

Some quick (pun not intended) comments:

- This is probably not the right mailing list to solicit comments on this
draft. I'd say the httpwg is a good place to get more eyes on this.

- RFC 6919 is a joke RFC, I don't think referring to that is a good idea.

- The compression negotiation seems very complicated, do clients/servers
really need that extreme flexibility with levels and bits?

- A 501 response code for not accepted feels weird as I don't think its the
server's fault. I would expect a 4xx code. Maybe just 403?

... I'm sure more will follow.

--

/ daniel.haxx.se

[Lucas Pardue]

On Thu, 29 Sep 2016, Van Catha wrote:

> So I took up this encouragement and wrote a draft for it
> https://github.com/vans163/websocket2-drafts/blob/master/websocket2-over-http2.txt.

What is the benefit of the payload size field defined in section 4?

[Patrick McManus]

Van, that's awesome - let's take this discussion to the IETF HTTP list and make this the last post in this thread on Google's list (the topic of which is google's implementation of quic - quite separate from the standards track). You'll find some folks over there interested in your work when you post it.

That list can be found at https://lists.w3.org/Archives/Public/ietf-http-wg/

-Patrick

--

You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.

[Ryan Hamilton]

On Fri, Sep 30, 2016 at 7:13 AM, Patrick McManus <mcm...@ducksong.com> wrote:

Van, that's awesome - let's take this discussion to the IETF HTTP list and make this the last post in this thread on Google's list (the topic of which is google's implementation of quic - quite separate from the standards track). You'll find some folks over there interested in your work when you post it.

That list can be found at https://lists.w3.org/Archives/Public/ietf-http-wg/

​+1. Thanks Van for kicking this off. I look forward to a more detailed discussion on the HTTP ​working group list!

[Van Catha]

Daniel Stenburg:  Haha, thanks for the analysis.  I answered your questions on the mailing list.

Lucas Pardue: As well thank you and answered.

Patrick McManus: Moved the discussion to the mailing list https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0615.html. Thank you for the guidance.

Lets see what we can come up with!