Discussion:
QUIC as device-driver
(too old to reply)
ElChino
2018-03-08 22:14:39 UTC
Permalink
I'm curious about the (much hyped?) Google protocol QUIC.
Ref e.g.


I see my Chrome browser is a heavy users of it (mainly to
Google sites naturally). But as far I understand QUIC is
mainly implemented in applications (Chrome etc.). Would it
not make more sense to support this in some kernel-driver?
Ref. how Windows has TCP-support in tcp.sys. Maybe some
OS'es already does this? Somebody know if this this would
be a good idea or not...

Barry, if you're there, is QUIC a hype or not?
Karl Kleinpaste
2018-03-08 22:51:55 UTC
Permalink
Would it not make more sense to support this in some kernel-driver?
Did you watch the video?

He explains the motivation reasonably well for a short video: The
priorities being considered are very application-specific.

Certainly it's possible that a generalized QUIC implementation for the
OS could be produced which has options for a variety of arbitrary kinds
of these applications (basic web page service -vs- email access -vs-
file transfer -vs- audio/video 1-way -vs- audio/video N-way interactive
-vs- ...), and then the applications written to use QUIC could specify
which of these generic profiles are desired. Offhand, and without
thinking it through too far, I envision this as a socket option kind of
concept, which unfortunately is where all the random crud like
TCP_NODELAY gets dumped for protocols; similar socket options named
QUIC_EMAIL and QUIC_XFER and so forth would at least fit there in a
somewhat orthogonal sense.

Insofar as they're apparently in the midst of experimenting, I can't say
I'm surprised that they're staying high up in application space so far.

It would be nice if, after having experimented for some time inside
Chrome and friends, Google could provide such a kernel implementation
plus some proof-of-concept reference applications that are written just
to show off what the protocol can do.

Loading...