QUIC Client-Server Distinctions

[Juan Benet]

Hello List,

I'd like to make a list of all the design decisions that differentiate a client vs a server in QUIC. QUIC may be a fantastic transport for fully distributed protocols (i.e. p2p, not client-server), but it's performance on embedded or resource constrained computers may depend greatly on client/server distinctions.[1]. So far, I've only noticed the odd/even stream numbering, and the Strike Register, which AGL mentioned will be removed anyway[2].

I'm wondering if there are other distinctions we should account for, particularly resource-expenditure asymmetries. Now would be a better time than later to reconsider or work around them.

I would be extremely grateful if QUIC used a "peer" model instead of "client + server" (more like TCP/UDP, less like HTTP/FTP). The distinction may seem small, but resource expenditure differences can impact application design and network topologies in a huge way. But, considering that the spec uses the word "server" 138 times, it is likely way too late to make it side-agnostic... 

Thanks,

Juan

[1] once "wearables" and "IoT" are in full swing, my watch should be able to tell my smoke alarm detectors to stop being obnoxious without going over other (layer 4) hops.

[2] https://groups.google.com/a/chromium.org/forum/#!searchin/proto-quic/peer$20to$20peer/proto-quic/aXlDBoA4gsA/3bcnuC1TWOYJ

[Ryan Hamilton]

Among other things, the "client" initiates the connection and sends "CHLO" messages in the handshake. The "server" does not initiate the connection and sends "REJ" or "SHLO" messages during the handshake. The server also presents a certificate to the client which the client verifies.

--
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.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Juan Benet]

Following up on this,

There is a recent ietf draft to possibly make HTTP2 more p2p friendly. (It actually came out of a discussion about exposing just the SPDY-based streams part of HTTP2 only, without all the HTTP overhead...).

I think it would be really, really powerful if QUIC were to be able to:

(a) expose just the data streams parts (without requiring the HTTP part). This so far seems to be done already-- it looks like libraries can just implement the streams muxing part without needing to layer HTTP on top.

(b) be a fully symmetric protocol, meaning do away with the client/server distinction.

As far as I can tell, the primary distinction between client and server is authentication: only servers must present certs. However, as i mentioned in another post today, this perhaps should be symmetric as well (or at least have the option for it to be).

Thus, if that is resolved, QUIC could be a completely symmetric, p2p, IoT friendly protocol. Is there interest in this?

[Ryan Hamilton]

QUIC endeavours to provide the same semantics as HTTP/2 (just over UDP instead of TCP which brings with it a bunch of advantages). As such, the HTTPbis ends up adopting those extensions, we would expect them to show up in QUIC as well, eventually.

Cheer,

Ryan

[Juan Benet]

For that draft, sure, though in reality they're less extensions and more downgrades (i.e. it relaxes some asymmetric constraints in stream opening).

However, i'm talking about something different here-- the QUIC spec is mostly about the transport (replaces all the streams stuff), and describes the use of HTTP2 as a layering on top of QUIC (as it should). I'm talking about making QUIC (the transport, the streams, etc) as asymmetric as possible. Auth was the main asymmetry, but it sounds like it won't be (for users who choose 2-way auth).

To put it another way, instead of libraries exposing two things:

        QuicClient

        QuicServer

        ... and derivatives

which implement almost the exact same behavior on each endpoint, but do slightly different things here and there, it is possible to implement both sides as the same thing:

        QuicConn

that behaves the same way at either endpoint -- with minor differences depending on who dialed (e.g. odd/even stream IDs thing), but overall no significant asymmetries. This is a huge win for p2p / IoT applications, as it prevents libraries from getting stuck in the client/server model, which doesn't work or impedes modes in many applications.

.. Does this express the point better? I can retry.

--
You received this message because you are subscribed to a topic in the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/proto-quic/Gf6Hi7XJFAc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to proto-quic+...@chromium.org.

[Ryan Hamilton]

I'm not sure if you're talking about the spec or the implementation. If you're talking about the implementation, we already expose a QuicConnection object which folks are welcome to extend in any way they wish. For HTTP/2 the notion of client and server are well defined and I expect us to continue to have QuicClient and QuicServer objects for the foreseeable future to implement this functionality. But but base functionality is there in QuicConnection to implement any sort of P2P classes you might want. For example, check out the net/quic/p2p/ directory in the chromium code base.

Cheers,

Ryan 

[Juan Benet]

Hey Ryan,

Thanks. this is exactly what i wanted from an implementation standpoint.

I guess my only remaining request is: please materialize the importance of these separate layers in the spec. i.e. make it clear that first there are bi-directional stream-muxing connections. Then HTTP2 is layered on top. And that implementations MAY (SHOULD?) provide this as an interface. In other words, it should be possible for implementations to implement just that (and none of the HTTP2 parts, and have a "QUIC-streams" library, even if not a full "HTTP/QUIC" library.  I mention this because people tend not to stray far from spec recommendations. The spec today is riddled with client/server wording, which leans very far toward the HTTP2 client/server model of the world, not the p2p-connections world. Without such guidance,o ther implementations of QUIC will likely fail to provide an interface like `net/quic/p2p`. (I just had to deal with this in both Go and Node.js with SPDY and HTTP2)

Anyway, not fair of me to ask without providing a concrete suggestion. I'll aim to take a look at all the spec docs and provide much more concrete suggestions, and hopefully a diff.

Thanks for the answers, and more importantly, for all the hard work on QUIC. I'm extremely excited for a future where QUIC runs everything. It's finally the next step we can all get behind.

Juan