15 ms·

Identifying QUIC deliverables

253 points by arusahni 8y ago

Lotus123 8y ago
It seems they are getting ahead of themselves...why should it be a good idea to burn the http/3 name now given the stage of development quic is in?
- xori 8y ago
  Names aren't sacred. Windows skipped 9 for technical reasons, iPhone skipped 9 for marketing reasons. They only people impacted by a skipped http/3 would be technical people upgrading from /2 to /4 in 5 years.
  - m_eiman 8y ago
    I really, really hope we're not going to be replacing fundamental low-level infrastructure code every five years. Keep the web frontend culture contained where it is now, don't let them ruin everything else too.
    - ocdtrekkie 8y ago
      Unfortunately, the low-level infrastructure of the web is now being controlled by a company which offers significant internal performance incentives for releasing new products.
      - dagenix 8y ago
        QUIC is hardly a product - very few users will ever know what it is. That Google has significant influence on internet infrastructure is hard to deny - but saying they are in control is ridiculous. And a lot of that influence comes from hiring really knowledgeable people - ignoring them just because they work for Google would be silly, especially for something like QUIC that is open and generally useful.
    - arusahni 8y ago
      I don't think of subsequent HTTP versions as replacing the previous ones - merely augmenting.
      - marcosdumay 8y ago
        So we'll need 3 servers instead of 1 just for serving HTTP?
        dagenix 8y ago
        Nginx can support HTTP 1.0, 1.1, and 2 all at once. I'd suspect one day it will be able to support 3 as well. And I'd imagine that any other server software of consequence is going to as well.
        marcosdumay 8y ago
        Yes, and the more protocols running, the less likely it is to ever be replaced some day. Who has the time to write 2 (1.0 and 1.1 are basically equal) servers for a minimum package? If somebody still sold HTTP servers, I would look how this one was bribing the standardizing process. But it looks like people are doing it freely.
        dagenix 8y ago
        I really can't figure out what you are saying. I don't see any evidence of bribery. And the technologies we're talking about have pretty legitimate reasons for existing. So, ...?
  - isostatic 8y ago
    > Windows skipped 9 for technical reasons Really? I thought it was because they don't plan to release another major version of windows, and wanted the number to have a nice solid "10", rather than a "9"
    - tialaramex 8y ago
      Idiots wrote code that says if osversion.startsWith('Windows 9') this is some crufty old Win9x system. To revert to the actual topic, to defend against this type of thing the QUIC binding for HTTP assigns an arbitrary non-contiguous group of identifiers as reserved to be ignored in various places, with the intent that some real systems will prod these once in a while, to discourage idiots hard-coding checks that will become obsolete.
      - SquareWheel 8y ago
        As far as I've seen, there was never any proof that Microsoft chose the Windows 10 name for that reason. I find it especially unlikely considering Vista broke even more recent compatibility.
        jcranmer 8y ago
        My recollection is that MS did confirm that Windows 10 was chosen for some vague mention of technical reasons, which most people latched on to as being explained by the "Windows 9" check. I have seen code in the 2010s that did explicitly check for "Windows 9" as a means to check if it was running on Windows 95 or 98. That doesn't mean that the code would actually work on those systems (it could well be a prelude to saying "your system is too ancient, we don't support you"). But such kind of cruft tends to last a very, very long time without active maintenance.
      - Dylan16807 8y ago
        Urban legend. Windows is already full of version APIs that lie to old programs. It could also format the name differently. And people like to quote broken java code, but old java would just say "Windows NT (unknown)". As a technical issue, it was small and easily avoided. It was a marketing decision.
tyingq 8y ago
"confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they're now separate things." Well, yeah, they have the same name. My first reaction to the headline was that lots of software isn't ready for http over udp.
- zamadatix 8y ago
  The protocol differences are miniscule as well, pretty much a version bit and ever so slightly slimmed header requirements IIRC. I remember reading it and thinking "cool, generalized QUIC... looks like I can built an HTTP-like transport with it and that's it". As for the HTTP over UDP, indeed - there is a reason Chrome has the ability to race a TCP connection alongside QUIC opens :).
- ksec 8y ago
  So what exactly is the QUIC-the-HTTP-binding? Everything on the web about QUIC is about UDP. It doesn't talk about HTTP/3 and /2 difference. /2 is already complex enough as it is.
  - tialaramex 8y ago
    QUIC offers a bunch of features HTTP wants. So this binding is about how you use those features. In some places HTTP/2 had a feature that QUIC now does better, in others QUIC offers something completely new. Rebinding is an example of the latter. When you change networks (and thus addresses) in QUIC it can update the ongoing connection seamlessly.
  - tveita 8y ago
    AIUI, the QUIC protocol [1] will be a general-purpose transport protocol built on top of UDP that offers multiple independent streams with encryption. For the application it's like it can open as many TCP connections as it wants, without the extra overhead from handshakes and rate control start. HTTP-over-QUIC [2] specifies how to talk HTTP 2 over the QUIC protocol, with some adjustments like using "native" QUIC streams instead of multiplexing streams over a TCP stream, and adjusting the header compression to allow more out-of-order operations. [1] https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ [2] https://datatracker.ietf.org/doc/draft-ietf-quic-http/ https://datatracker.ietf.org/doc/draft-ietf-quic-http/
anentropic 8y ago
I had to disable QUIC in Chrome a few days ago, was completely unable to access YouTube, and google.com search only intermittently maybe they need to make it work first
- unethical_ban 8y ago
  Web proxy software isn't quite ready for it AFAICT.
- DanielDent 8y ago
  One of the ways to get it working is to get more people using it... QUIC is implemented with a number of fallbacks to deal with broken networks, but at some point it's probably better to just let things break and force network operators to fix their broken networks.
mobilemidget 8y ago
Seeing how long we have used http 1.0/1.1 (and still); and http/2.0 far from fully adopted, I'm somewhat surprised to see v3 being discussed already and v4 being mentioned in there. Though maybe it requires way more future vision and planning then I expect.
- gcb0 8y ago
  its all mostly driven by Google pushing thu with chrome constant updates. they can update chrome tomorrow to v3, v4, v10... it's all the same. on http2/spdy, they at least had the decency to publish something before forcing everyone into adoption
  - gregmac 8y ago
    It helps that this also pushed the other browser vendors to step up their games. Firefox switched to a Rapid Release cycle. Even Microsoft is now on board with Edge updating fairly regularly (at least compared to IE). A few years ago, web sites and infrastructure had to be built to serve decade-old versions. Now it's reasonable to support only a few years-old versions, and this time frame is continuously shrinking as the current generation of evergreen auto-updating browsers takes more market share. Though I don't like the bit about forcing adoption onto others, I do think that advancing the market to allow standards changes like this to happen in years instead of decades is a good thing.
    - h1d 8y ago
      Too bad Windows 10 isn't exactly everyone's favorite and thus IE is still around for some time.
    - gcb0 8y ago
      dont drink google coolaid! they all already have ways to release security patches. firefox has a semi-secret/invisible system addon for that. so much that this is still the current way to release security patches and fix internet-breaking bugs. rapid release for new features eas invented by microsoft with IE, to push the agenda on standards bodies. it moved so fast that nonody even remember IE5 or 5.5... and thats the reason google have rapid release. nothing to do with security, as proved on the 1st paragraph.
sametmax 8y ago
When http2 will be widely adopted by most small companies, and not just big ones, yeah, let's talk about v2. But right now, http2 adds complexity, a lot of frameworks are not compatible with it and must be fronted by a proxy that does, and the perf benefit is not obvious at all.
- xroche 8y ago
  The perf benefits are mainly for the big companies [namely, Google, Mozilla, and few others]. Hard to see any real ones for the rest of the world.
  - zamadatix 8y ago
    The punishments for not "building/packaging/spriting" your website/app are way lower thanks to the multiplexing. Smaller shops either didn't know or didn't have the time to care about this and it added seconds to the page load in many cases. Now it's fixed (not that you shouldn't still build/package/sprite in appropriate cases) by just using HTTP/2.
    - sametmax 8y ago
      A shop that doesn't do package/sprinting is unlikely to even know about http2 nor being able to deploy it. I doubt you can setup nginx if you can't even run a minifier from the command line.
      - SEJeff 8y ago
        CPanel hosted websites... Hold my css
      - londons_explore 8y ago
        They typically use web hosts who will deploy http/2 for you.
  - drewg123 8y ago
    The problem is that QUIC, due to using UDP and not trusting the NIC to do segmentation or crypto offload, is incredibly expensive on the server side. You're paying costs upwards of a factor of 4 as compared to TCP for quality of experience gains that are questionable when compared to TCP. This doesn't matter for small sites, or for clients. But when you're serving 190Gb/s from a single box, paying 4x per byte really hurts.
maxfurman 8y ago
https://en.wikipedia.org/wiki/QUIC https://en.wikipedia.org/wiki/QUIC, for those like me wondering what it is. I think it's funny that the Q in QUIC stands for Quick. Naming things is hard.
- Cyph0n 8y ago
  That reminds of me recursive acronyms[0]. Some examples: * GNU: GNU's Not Unix * cURL: Curl URL Request Library * WINE: WINE Is Not an Emulator [0]: https://en.wikipedia.org/wiki/Recursive_acronym https://en.wikipedia.org/wiki/Recursive_acronym
  - tech2 8y ago
    One of my all time favourites was Xinu (Xinu is not Unix), much more so than the doubly-weird Hurd.
  - SEJeff 8y ago
    GNOME - "GNU's Not Unix" Network Object Modelling Environment!
  - diydsp 8y ago
    From the old days when it ran on slow hardware: Emacs Makes A Computer Slow
    - teddyh 8y ago
      No, that’s a joke. The ones you commented on are all the official definitions.
- simias 8y ago
  Recursive acronyms are a staple of hacker culture by now. There's of course GNU (and many GNU projects) but also PHP, PINE and many backronyms like XBMC: https://en.wikipedia.org/wiki/Recursive_acronym https://en.wikipedia.org/wiki/Recursive_acronym
  - 8y ago
detaro 8y ago
Seems to me there is a difference between "we're gonna propose that naming" and "will most likely be"? That said, it doesn't seem like a good idea to me, since it's less of a clear protocol evolution. A variation of the http/2 name would IMHO make more sense, e.g. http/2q or something, since it's not changing the HTTP semantics.
- bpicolo 8y ago
  To be fair, helps that this is coming from the chair of the IETF HTTP working group
  - arusahni 8y ago
    That was my thought in constructing the title for this post. Apologies if I failed to capture the appropriate level of nuance.
    - detaro 8y ago
      I might very well be wrong with my interpretation of the politics involved, and you right :D
- gsnedders 8y ago
  > A variation of the http/2 name would IMHO make more sense, e.g. http/2q or something, since it's not changing the HTTP semantics. HTTP/2 didn't change semantics, either. We literally only have one version of HTTP semantics, and a variety of transports for it.
- h1d 8y ago
  Please keep it with simple numbers, we don't want to go the wifi route of a/b/g/n/ac where you can't tell what is more modern which they fixed.
- Matthias247 8y ago
  > A variation of the http/2 name would IMHO make more sense Why? The core of HTTP/2 is defining how individual HTTP streams get multiplexed across a single TCP connection. That part is not applicable to QUIC over HTTP. There HTTP streams get mapped on top of QUIC streams. Some things might be similar between HTTP/2 and HTTP/QUIC mappings, but in the end they are separate definitions. The both define how HTTP semantics are carried over a different lower layer mechanism. So HTTP/3 or HTTP/QUIC seem reasonable.
plopz 8y ago
Not being familiar at all with QUIC other than it has something to do with UDP. Would this have any impact on being able to send/receive UDP from the browser for games?
- the_clarence 8y ago
  QUIC is like TCP 2.0. So it won't help games
  - Dylan16807 8y ago
    It'll probably get a non-blocking option. And some games need TCP anyway.
  - Matthias247 8y ago
    Even if quic would bring along an unreliable stream option: The browsers Api still only expose http semantics via xhr and fetch. So those would need to get extended too.
    - Dylan16807 8y ago
      I would imagine it as something like an option on websockets, so it wouldn't take much API work. Actually doesn't webRTC already have unreliable channels?
      - Matthias247 8y ago
        Sure there are possibilities, but they all require additional standardization (which takes time and effort). WebRTC has unreliable data channels, but they are based on sctp/dtls/udp. Making them work over quic streams might be possible, but also requires a new standardization effort. If someone does it I would actually prefer an API outside of webrtc, since that one carries a lot of complexity for signaling and requires again a few extra protocols (ice, stun, turn, etc). An unreliable/unordered client to server protocol and api could potentially be much simpler.
mtgx 8y ago
If we're really looking to start from scratch with a modern protocol and break compatibility then HTTP v3 should be something like http://noiseprotocol.org http://noiseprotocol.org instead. I assume the QUIC protocol also comes with some "happy accidents" that allows Google to more easily collect data on us, too.
- dagenix 8y ago
  > I assume the QUIC protocol also comes with some "happy accidents" that allows Google to more easily collect data on us, too. This is just conspiracy theory nonsense. If QUIC has such a flaw, it has an open spec and you are free to go find it and point it out.
  - teddyh 8y ago
    Pointing it out would change nothing; Google would implement it anyway.
    - dagenix 8y ago
      So? If what is claimed to be true is true, maybe Apple, Mozilla, and Microsoft won't implement it - and that would be a big deal to the alleged nefarious plot. But, that won't happen if no one speaks up. That is, of course, if this isn't just nonsense speculation.
- baby 8y ago
  This is exactly what we've been working on (QUIC with Noise). As for the happy accidents, none have been spotted so far, it is an open and collaborative project so feel free to check it yourself and chime in before its finalization.
dustingetz 8y ago
Is QUIC what is disrupting my video calls when I type into a google doc from chrome, or any other chrome->google interaction?
- vntok 8y ago
  No.
rebelde 8y ago
Interesting. Google has been pushing TLS on the world, with its additional 750ms round-trip time to clients on the other side of the world, while taking advantage of their ownership of Chrome to use QUIC to deliver very fast connectivity for their users. That is a sweet competitive advantage that they have over competing services. EDIT: Am I misunderstanding this?
- tialaramex 8y ago
  If you are False Start compatible (allow modern ECDHE, etcetera and speak HTTP/2, don't use crappy middleboxes from Cisco, Palo Alto) you get 1RTT with TLS 1.2. If you do TLS 1.3 you always get 1RTT. You can't avoid the one round trip on first connections, you pay that in QUIC too.
  - xfs 8y ago
    There's 0RTT but once the connection setup cost is amortized by preconnects and multiplexing being 0 or 1 RTT is not that important to justify its engineering ugliness.
  - the_clarence 8y ago
    Isn't QUIC mixing the tcp handshake with the tls handshake? That should make it faster
- londons_explore 8y ago
  If you trust people like cloudflare to do CDN termination for you, that time penalty is far lower. There is also a proposal to allow connection sharing for different domains, which would reduce the connection time to 0-rtt even if the user has never visited your site.
mychele 8y ago
From what I understand, this email is proposing to update the name of the RFC for HTTP over QUIC, not QUIC itself.
ArtWomb 8y ago
Google Cloud introduced QUIC support recently for load balancing https://cloudplatform.googleblog.com/2018/06/Introducing-QUIC-support-for-HTTPS-load-balancing.html https://cloudplatform.googleblog.com/2018/06/Introducing-QUI... Adoption of cloud gaming is accelerating. And we are already starting to see custom protocols in the wild https://blog.parsecgaming.com/a-networking-protocol-built-for-the-lowest-latency-interactive-game-streaming-1fd5a03a6007 https://blog.parsecgaming.com/a-networking-protocol-built-fo...
- the_clarence 8y ago
  QUIC is effectively TCP 2.0. It is not a lossy protocol which is what games need.
LinuxBender 8y ago
Somewhat OT, if v3 has not yet been ratified, is there a chance to get SRV record support added for http? That could indirectly tie into QUIC optimization.
- teddyh 8y ago
  It would be wonderful, but not likely, since Google is pushing it, and they gave completely spurious reasons for not including it in HTTP/2. I see no reason for this to be any different.
- wmf 8y ago
  You'd need Chrome to do some SRV experiments for a few years before proposing it.
- chaz6 8y ago
  There is a 19-year old bug open for SRV support in Firefox [1] and it recently got updated (marked as blocking #1435798 APIs for p2p web applications) [1] https://bugzilla.mozilla.org/show_bug.cgi?id=14328 https://bugzilla.mozilla.org/show_bug.cgi?id=14328
- londons_explore 8y ago
  The goal would be to use a SRV record rather than an A record for http? Whats the benefit?
  - wmf 8y ago
    Using ports other than 443.
    - teddyh 8y ago
      And load balancing without a separate server to act as a load balancer in front. Just announce a bunch of servers and all clients will all just pick one, with the ratio of servers which you adjust! No more proxy!
      - 8y ago
QuadrupleA 8y ago
This was the first I heard of QUIC - having dealt a lot with crypto libraries, https, TLS etc. it sounds super promising. Gets rid of a lot of old-cipher cruft and TLS latency, bake security into to the transport, multiplex connections etc. Some really cool ideas there.
- the_clarence 8y ago
  QUIC uses TLS.
- lucb1e 8y ago
  I heard of it before and later also got it in school (wouldn't recommend the study but this one subject by Paola Grosso was superb). Definitely cool stuff.
- ori_b 8y ago
  Let's see a few independent implementations before we start using it. As far as I can tell, this is also horrendously complicated, and I'm not aware of any implementations outside of Google's.
  - wmf 8y ago
    https://github.com/quicwg/base-drafts/wiki/Implementations https://github.com/quicwg/base-drafts/wiki/Implementations
    - nicoburns 8y ago
      This one wins the best name competition https://github.com/ghedo/quiche https://github.com/ghedo/quiche
the_other_guy 8y ago
Does QUIC provide any advantage for wireless connections over TCP/TLS? Also, does QUIC use DTLS or something that's more customized?
- the_clarence 8y ago
  It uses TLS 1.3. No need for DTLS as QUIC isan in-order protocol (eventhough it's built on top of UDP). It is supposed to be faster than tcp+tls
- londons_explore 8y ago
  It is especially beneficial for wireless connections, since it handles packet loss better than http/2, and flow control better than many http/1.1 connections.
pentagonpapers 8y ago
It's high time for HTTP 0. http://http02.cat-v.org/ http://http02.cat-v.org/
KaiserPro 8y ago
Why does it still adhere to the weird semantics of HTTP, when in reality HTTP has evolved into a file delivery protocol, with a rich inband messaging system? Surely we have an opportunity to split HTTP into a file delivery system and a socket-like streaming system?
fulafel 8y ago
Meanwhile we are still waiting for http 1.1 pipelining to be enabled in browsers.
- wmf 8y ago
  Stop waiting; there's no reason to work on this any more. If you want pipelining that bad, use HTTP/2.
ggm 8y ago
Don't people read about the OSI/ISO 7 layer model any more? The biggest deliverable (to me at least) of QUIC is the formalism of a "session" layer which is transport binding agnostic: If you move to alternate underlying IP addresses, it can recover and continue. Sessions were big in OSI. Internet applications/protocol stack basically ignored them, for reasons of NIH, complexity, place-and-time. But, Session layer is inherently useful UDP? Schmoo Dee Pee. What matters to me, is a session layer with cryptography. (ok. taste-testing the underlying fragmentation barriers, which was in an earlier QUIC, that was interesting because pMTU is broken)

253 points by arusahni 8y ago

It seems they are getting ahead of themselves...why should it be a good idea to burn the http/3 name now given the stage of development quic is in?

xori 8y ago
Names aren't sacred. Windows skipped 9 for technical reasons, iPhone skipped 9 for marketing reasons. They only people impacted by a skipped http/3 would be technical people upgrading from /2 to /4 in 5 years.
- m_eiman 8y ago
  I really, really hope we're not going to be replacing fundamental low-level infrastructure code every five years. Keep the web frontend culture contained where it is now, don't let them ruin everything else too.
  - ocdtrekkie 8y ago
    Unfortunately, the low-level infrastructure of the web is now being controlled by a company which offers significant internal performance incentives for releasing new products.
    - dagenix 8y ago
      QUIC is hardly a product - very few users will ever know what it is. That Google has significant influence on internet infrastructure is hard to deny - but saying they are in control is ridiculous. And a lot of that influence comes from hiring really knowledgeable people - ignoring them just because they work for Google would be silly, especially for something like QUIC that is open and generally useful.
  - arusahni 8y ago
    I don't think of subsequent HTTP versions as replacing the previous ones - merely augmenting.
    - marcosdumay 8y ago
      So we'll need 3 servers instead of 1 just for serving HTTP?
      - dagenix 8y ago
        Nginx can support HTTP 1.0, 1.1, and 2 all at once. I'd suspect one day it will be able to support 3 as well. And I'd imagine that any other server software of consequence is going to as well.
        marcosdumay 8y ago
        Yes, and the more protocols running, the less likely it is to ever be replaced some day. Who has the time to write 2 (1.0 and 1.1 are basically equal) servers for a minimum package? If somebody still sold HTTP servers, I would look how this one was bribing the standardizing process. But it looks like people are doing it freely.
        dagenix 8y ago
        I really can't figure out what you are saying. I don't see any evidence of bribery. And the technologies we're talking about have pretty legitimate reasons for existing. So, ...?
- isostatic 8y ago
  > Windows skipped 9 for technical reasons Really? I thought it was because they don't plan to release another major version of windows, and wanted the number to have a nice solid "10", rather than a "9"
  - tialaramex 8y ago
    Idiots wrote code that says if osversion.startsWith('Windows 9') this is some crufty old Win9x system. To revert to the actual topic, to defend against this type of thing the QUIC binding for HTTP assigns an arbitrary non-contiguous group of identifiers as reserved to be ignored in various places, with the intent that some real systems will prod these once in a while, to discourage idiots hard-coding checks that will become obsolete.
    - SquareWheel 8y ago
      As far as I've seen, there was never any proof that Microsoft chose the Windows 10 name for that reason. I find it especially unlikely considering Vista broke even more recent compatibility.
      - jcranmer 8y ago
        My recollection is that MS did confirm that Windows 10 was chosen for some vague mention of technical reasons, which most people latched on to as being explained by the "Windows 9" check. I have seen code in the 2010s that did explicitly check for "Windows 9" as a means to check if it was running on Windows 95 or 98. That doesn't mean that the code would actually work on those systems (it could well be a prelude to saying "your system is too ancient, we don't support you"). But such kind of cruft tends to last a very, very long time without active maintenance.
    - Dylan16807 8y ago
      Urban legend. Windows is already full of version APIs that lie to old programs. It could also format the name differently. And people like to quote broken java code, but old java would just say "Windows NT (unknown)". As a technical issue, it was small and easily avoided. It was a marketing decision.

tyingq 8y ago

"confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they're now separate things." Well, yeah, they have the same name. My first reaction to the headline was that lots of software isn't ready for http over udp.

zamadatix 8y ago
The protocol differences are miniscule as well, pretty much a version bit and ever so slightly slimmed header requirements IIRC. I remember reading it and thinking "cool, generalized QUIC... looks like I can built an HTTP-like transport with it and that's it". As for the HTTP over UDP, indeed - there is a reason Chrome has the ability to race a TCP connection alongside QUIC opens :).
ksec 8y ago
So what exactly is the QUIC-the-HTTP-binding? Everything on the web about QUIC is about UDP. It doesn't talk about HTTP/3 and /2 difference. /2 is already complex enough as it is.
- tialaramex 8y ago
  QUIC offers a bunch of features HTTP wants. So this binding is about how you use those features. In some places HTTP/2 had a feature that QUIC now does better, in others QUIC offers something completely new. Rebinding is an example of the latter. When you change networks (and thus addresses) in QUIC it can update the ongoing connection seamlessly.
- tveita 8y ago
  AIUI, the QUIC protocol [1] will be a general-purpose transport protocol built on top of UDP that offers multiple independent streams with encryption. For the application it's like it can open as many TCP connections as it wants, without the extra overhead from handshakes and rate control start. HTTP-over-QUIC [2] specifies how to talk HTTP 2 over the QUIC protocol, with some adjustments like using "native" QUIC streams instead of multiplexing streams over a TCP stream, and adjusting the header compression to allow more out-of-order operations. [1] https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ [2] https://datatracker.ietf.org/doc/draft-ietf-quic-http/ https://datatracker.ietf.org/doc/draft-ietf-quic-http/

anentropic 8y ago

I had to disable QUIC in Chrome a few days ago, was completely unable to access YouTube, and google.com search only intermittently maybe they need to make it work first

unethical_ban 8y ago
Web proxy software isn't quite ready for it AFAICT.
DanielDent 8y ago
One of the ways to get it working is to get more people using it... QUIC is implemented with a number of fallbacks to deal with broken networks, but at some point it's probably better to just let things break and force network operators to fix their broken networks.

mobilemidget 8y ago

Seeing how long we have used http 1.0/1.1 (and still); and http/2.0 far from fully adopted, I'm somewhat surprised to see v3 being discussed already and v4 being mentioned in there. Though maybe it requires way more future vision and planning then I expect.

gcb0 8y ago
its all mostly driven by Google pushing thu with chrome constant updates. they can update chrome tomorrow to v3, v4, v10... it's all the same. on http2/spdy, they at least had the decency to publish something before forcing everyone into adoption
- gregmac 8y ago
  It helps that this also pushed the other browser vendors to step up their games. Firefox switched to a Rapid Release cycle. Even Microsoft is now on board with Edge updating fairly regularly (at least compared to IE). A few years ago, web sites and infrastructure had to be built to serve decade-old versions. Now it's reasonable to support only a few years-old versions, and this time frame is continuously shrinking as the current generation of evergreen auto-updating browsers takes more market share. Though I don't like the bit about forcing adoption onto others, I do think that advancing the market to allow standards changes like this to happen in years instead of decades is a good thing.
  - h1d 8y ago
    Too bad Windows 10 isn't exactly everyone's favorite and thus IE is still around for some time.
  - gcb0 8y ago
    dont drink google coolaid! they all already have ways to release security patches. firefox has a semi-secret/invisible system addon for that. so much that this is still the current way to release security patches and fix internet-breaking bugs. rapid release for new features eas invented by microsoft with IE, to push the agenda on standards bodies. it moved so fast that nonody even remember IE5 or 5.5... and thats the reason google have rapid release. nothing to do with security, as proved on the 1st paragraph.

sametmax 8y ago

When http2 will be widely adopted by most small companies, and not just big ones, yeah, let's talk about v2. But right now, http2 adds complexity, a lot of frameworks are not compatible with it and must be fronted by a proxy that does, and the perf benefit is not obvious at all.

xroche 8y ago
The perf benefits are mainly for the big companies [namely, Google, Mozilla, and few others]. Hard to see any real ones for the rest of the world.
- zamadatix 8y ago
  The punishments for not "building/packaging/spriting" your website/app are way lower thanks to the multiplexing. Smaller shops either didn't know or didn't have the time to care about this and it added seconds to the page load in many cases. Now it's fixed (not that you shouldn't still build/package/sprite in appropriate cases) by just using HTTP/2.
  - sametmax 8y ago
    A shop that doesn't do package/sprinting is unlikely to even know about http2 nor being able to deploy it. I doubt you can setup nginx if you can't even run a minifier from the command line.
    - SEJeff 8y ago
      CPanel hosted websites... Hold my css
    - londons_explore 8y ago
      They typically use web hosts who will deploy http/2 for you.
- drewg123 8y ago
  The problem is that QUIC, due to using UDP and not trusting the NIC to do segmentation or crypto offload, is incredibly expensive on the server side. You're paying costs upwards of a factor of 4 as compared to TCP for quality of experience gains that are questionable when compared to TCP. This doesn't matter for small sites, or for clients. But when you're serving 190Gb/s from a single box, paying 4x per byte really hurts.

maxfurman 8y ago

https://en.wikipedia.org/wiki/QUIC https://en.wikipedia.org/wiki/QUIC, for those like me wondering what it is. I think it's funny that the Q in QUIC stands for Quick. Naming things is hard.

Cyph0n 8y ago
That reminds of me recursive acronyms[0]. Some examples: * GNU: GNU's Not Unix * cURL: Curl URL Request Library * WINE: WINE Is Not an Emulator [0]: https://en.wikipedia.org/wiki/Recursive_acronym https://en.wikipedia.org/wiki/Recursive_acronym
- tech2 8y ago
  One of my all time favourites was Xinu (Xinu is not Unix), much more so than the doubly-weird Hurd.
- SEJeff 8y ago
  GNOME - "GNU's Not Unix" Network Object Modelling Environment!
- diydsp 8y ago
  From the old days when it ran on slow hardware: Emacs Makes A Computer Slow
  - teddyh 8y ago
    No, that’s a joke. The ones you commented on are all the official definitions.
simias 8y ago
Recursive acronyms are a staple of hacker culture by now. There's of course GNU (and many GNU projects) but also PHP, PINE and many backronyms like XBMC: https://en.wikipedia.org/wiki/Recursive_acronym https://en.wikipedia.org/wiki/Recursive_acronym
- 8y ago

detaro 8y ago

Seems to me there is a difference between "we're gonna propose that naming" and "will most likely be"? That said, it doesn't seem like a good idea to me, since it's less of a clear protocol evolution. A variation of the http/2 name would IMHO make more sense, e.g. http/2q or something, since it's not changing the HTTP semantics.

bpicolo 8y ago
To be fair, helps that this is coming from the chair of the IETF HTTP working group
- arusahni 8y ago
  That was my thought in constructing the title for this post. Apologies if I failed to capture the appropriate level of nuance.
  - detaro 8y ago
    I might very well be wrong with my interpretation of the politics involved, and you right :D
gsnedders 8y ago
> A variation of the http/2 name would IMHO make more sense, e.g. http/2q or something, since it's not changing the HTTP semantics. HTTP/2 didn't change semantics, either. We literally only have one version of HTTP semantics, and a variety of transports for it.
h1d 8y ago
Please keep it with simple numbers, we don't want to go the wifi route of a/b/g/n/ac where you can't tell what is more modern which they fixed.
Matthias247 8y ago
> A variation of the http/2 name would IMHO make more sense Why? The core of HTTP/2 is defining how individual HTTP streams get multiplexed across a single TCP connection. That part is not applicable to QUIC over HTTP. There HTTP streams get mapped on top of QUIC streams. Some things might be similar between HTTP/2 and HTTP/QUIC mappings, but in the end they are separate definitions. The both define how HTTP semantics are carried over a different lower layer mechanism. So HTTP/3 or HTTP/QUIC seem reasonable.

plopz 8y ago

Not being familiar at all with QUIC other than it has something to do with UDP. Would this have any impact on being able to send/receive UDP from the browser for games?

the_clarence 8y ago
QUIC is like TCP 2.0. So it won't help games
- Dylan16807 8y ago
  It'll probably get a non-blocking option. And some games need TCP anyway.
- Matthias247 8y ago
  Even if quic would bring along an unreliable stream option: The browsers Api still only expose http semantics via xhr and fetch. So those would need to get extended too.
  - Dylan16807 8y ago
    I would imagine it as something like an option on websockets, so it wouldn't take much API work. Actually doesn't webRTC already have unreliable channels?
    - Matthias247 8y ago
      Sure there are possibilities, but they all require additional standardization (which takes time and effort). WebRTC has unreliable data channels, but they are based on sctp/dtls/udp. Making them work over quic streams might be possible, but also requires a new standardization effort. If someone does it I would actually prefer an API outside of webrtc, since that one carries a lot of complexity for signaling and requires again a few extra protocols (ice, stun, turn, etc). An unreliable/unordered client to server protocol and api could potentially be much simpler.

mtgx 8y ago

If we're really looking to start from scratch with a modern protocol and break compatibility then HTTP v3 should be something like http://noiseprotocol.org http://noiseprotocol.org instead. I assume the QUIC protocol also comes with some "happy accidents" that allows Google to more easily collect data on us, too.

dagenix 8y ago
> I assume the QUIC protocol also comes with some "happy accidents" that allows Google to more easily collect data on us, too. This is just conspiracy theory nonsense. If QUIC has such a flaw, it has an open spec and you are free to go find it and point it out.
- teddyh 8y ago
  Pointing it out would change nothing; Google would implement it anyway.
  - dagenix 8y ago
    So? If what is claimed to be true is true, maybe Apple, Mozilla, and Microsoft won't implement it - and that would be a big deal to the alleged nefarious plot. But, that won't happen if no one speaks up. That is, of course, if this isn't just nonsense speculation.
baby 8y ago
This is exactly what we've been working on (QUIC with Noise). As for the happy accidents, none have been spotted so far, it is an open and collaborative project so feel free to check it yourself and chime in before its finalization.

dustingetz 8y ago

Is QUIC what is disrupting my video calls when I type into a google doc from chrome, or any other chrome->google interaction?

vntok 8y ago
No.

rebelde 8y ago

Interesting. Google has been pushing TLS on the world, with its additional 750ms round-trip time to clients on the other side of the world, while taking advantage of their ownership of Chrome to use QUIC to deliver very fast connectivity for their users. That is a sweet competitive advantage that they have over competing services. EDIT: Am I misunderstanding this?

tialaramex 8y ago
If you are False Start compatible (allow modern ECDHE, etcetera and speak HTTP/2, don't use crappy middleboxes from Cisco, Palo Alto) you get 1RTT with TLS 1.2. If you do TLS 1.3 you always get 1RTT. You can't avoid the one round trip on first connections, you pay that in QUIC too.
- xfs 8y ago
  There's 0RTT but once the connection setup cost is amortized by preconnects and multiplexing being 0 or 1 RTT is not that important to justify its engineering ugliness.
- the_clarence 8y ago
  Isn't QUIC mixing the tcp handshake with the tls handshake? That should make it faster
londons_explore 8y ago
If you trust people like cloudflare to do CDN termination for you, that time penalty is far lower. There is also a proposal to allow connection sharing for different domains, which would reduce the connection time to 0-rtt even if the user has never visited your site.

mychele 8y ago

From what I understand, this email is proposing to update the name of the RFC for HTTP over QUIC, not QUIC itself.

ArtWomb 8y ago

Google Cloud introduced QUIC support recently for load balancing https://cloudplatform.googleblog.com/2018/06/Introducing-QUIC-support-for-HTTPS-load-balancing.html https://cloudplatform.googleblog.com/2018/06/Introducing-QUI... Adoption of cloud gaming is accelerating. And we are already starting to see custom protocols in the wild https://blog.parsecgaming.com/a-networking-protocol-built-for-the-lowest-latency-interactive-game-streaming-1fd5a03a6007 https://blog.parsecgaming.com/a-networking-protocol-built-fo...

the_clarence 8y ago
QUIC is effectively TCP 2.0. It is not a lossy protocol which is what games need.

LinuxBender 8y ago

Somewhat OT, if v3 has not yet been ratified, is there a chance to get SRV record support added for http? That could indirectly tie into QUIC optimization.

teddyh 8y ago
It would be wonderful, but not likely, since Google is pushing it, and they gave completely spurious reasons for not including it in HTTP/2. I see no reason for this to be any different.
wmf 8y ago
You'd need Chrome to do some SRV experiments for a few years before proposing it.
chaz6 8y ago
There is a 19-year old bug open for SRV support in Firefox [1] and it recently got updated (marked as blocking #1435798 APIs for p2p web applications) [1] https://bugzilla.mozilla.org/show_bug.cgi?id=14328 https://bugzilla.mozilla.org/show_bug.cgi?id=14328
londons_explore 8y ago
The goal would be to use a SRV record rather than an A record for http? Whats the benefit?
- wmf 8y ago
  Using ports other than 443.
  - teddyh 8y ago
    And load balancing without a separate server to act as a load balancer in front. Just announce a bunch of servers and all clients will all just pick one, with the ratio of servers which you adjust! No more proxy!
    - 8y ago

QuadrupleA 8y ago

This was the first I heard of QUIC - having dealt a lot with crypto libraries, https, TLS etc. it sounds super promising. Gets rid of a lot of old-cipher cruft and TLS latency, bake security into to the transport, multiplex connections etc. Some really cool ideas there.

the_clarence 8y ago
QUIC uses TLS.
lucb1e 8y ago
I heard of it before and later also got it in school (wouldn't recommend the study but this one subject by Paola Grosso was superb). Definitely cool stuff.
ori_b 8y ago
Let's see a few independent implementations before we start using it. As far as I can tell, this is also horrendously complicated, and I'm not aware of any implementations outside of Google's.
- wmf 8y ago
  https://github.com/quicwg/base-drafts/wiki/Implementations https://github.com/quicwg/base-drafts/wiki/Implementations
  - nicoburns 8y ago
    This one wins the best name competition https://github.com/ghedo/quiche https://github.com/ghedo/quiche

the_other_guy 8y ago

Does QUIC provide any advantage for wireless connections over TCP/TLS? Also, does QUIC use DTLS or something that's more customized?

the_clarence 8y ago
It uses TLS 1.3. No need for DTLS as QUIC isan in-order protocol (eventhough it's built on top of UDP). It is supposed to be faster than tcp+tls
londons_explore 8y ago
It is especially beneficial for wireless connections, since it handles packet loss better than http/2, and flow control better than many http/1.1 connections.

pentagonpapers 8y ago

It's high time for HTTP 0. http://http02.cat-v.org/ http://http02.cat-v.org/

KaiserPro 8y ago

Why does it still adhere to the weird semantics of HTTP, when in reality HTTP has evolved into a file delivery protocol, with a rich inband messaging system? Surely we have an opportunity to split HTTP into a file delivery system and a socket-like streaming system?

fulafel 8y ago

Meanwhile we are still waiting for http 1.1 pipelining to be enabled in browsers.

wmf 8y ago
Stop waiting; there's no reason to work on this any more. If you want pipelining that bad, use HTTP/2.

ggm 8y ago

Don't people read about the OSI/ISO 7 layer model any more? The biggest deliverable (to me at least) of QUIC is the formalism of a "session" layer which is transport binding agnostic: If you move to alternate underlying IP addresses, it can recover and continue. Sessions were big in OSI. Internet applications/protocol stack basically ignored them, for reasons of NIH, complexity, place-and-time. But, Session layer is inherently useful UDP? Schmoo Dee Pee. What matters to me, is a session layer with cryptography. (ok. taste-testing the underlying fragmentation barriers, which was in an earlier QUIC, that was interesting because pMTU is broken)