5 ms·

QUIC's connection migration feature is really amazing for applications where you switch IPs, e.g. when your phone goes from mobile data to Wifi. Another nice th

QUIC's connection migration feature is really amazing for applications where you switch IPs, e.g. when your phone goes from mobile data to Wifi. Another nice thing is that you can cache sessions and resume them later, so connections can even survive reboots and server failures, or you can move them between different machines. TCPLS seems like a good proposal but I won't hold my breath for it as the big players like Cloudflare, Google, Akamai, Fastly are already committed to QUIC. There's still significant churn in the proposals and some features like MASQUE are still being finalized, but overall QUIC works really well.

stormbrew 4y ago
I'm not a huge fan of how spdy and then quic were kinda ramrodded into the HTTP standards process, but realistically I think QUIC is basically the future of connection transport wherever tcp or udp alone are failing at this point. I recently discovered the nQuick proposal to do noise-based connection initiation for peer-to-peer connections and I love it[1]. It's an incredibly versatile protocol. It seems likely that a lot of the issues raised in the OP will be somewhat forced to be resolved due to the aforementioned ramrodding of QUIC into the HTTP3 path, but maybe in the long run the two ideas will co-evolve to the same solution. [1] https://eprint.iacr.org/2019/028.pdf https://eprint.iacr.org/2019/028.pdf
- unmole 4y ago
  > quic were kinda ramrodded into the HTTP standards process QUIC took 4 years and 34 drafts to get standardized. The final IETF version is significantly different from Google initially came up with. So, no it most definitely was not ramrodded through.
  - stormbrew 4y ago
    I didn't say quic itself was -- if quic had been introduced completely independently of http then sure, that's fine. But it was introduced intermingled with making yet another drastic change to a backbone protocol of the internet. Considering HTTP/1.1 stood for over 15 years before http/2 came along (and was a pretty modest improvement over http/1.0 compared to what we're talking about now, so I'm being generous by not saying over 20 years). http/2 had only been promoted to a proposed standard for 3 before http/3 was proposed. That, to me, is a very aggressive process. But again, it's the relationship to http that bothers me, not the standardization process for quic itself.
    - unmole 4y ago
      What's the point of having QUIC if there isn't a protocol that actually uses it? And what would be a better protocol than HTTP? HTTP/2 was a marginal improvement but HTTP/3 and QUIC significantly improve user experience. Especially if the users have jittery networks which is the case for the majority of the world. I don't understand why it would have been a better idea to sit on these improvements for a while before getting them into the hands of users.
      - stormbrew 4y ago
        I don't really see "is it beneficial in the long run" and "is it an aggressive standardization campaign by one interested party" as being the same question. At any rate I also didn't say they shouldn't experiment with using it as an accelerated path for http. I didn't think they shouldn't with spdy either. But historically RFCs were built on practice, not the other way around. If I were the Internet Dictator, I'd be a big fan of standardizing the semantics of http separate from the physical transport and then defining best practices for using alternative transports in the wild, and then eventually standardizing what comes out of that process. To me it's an indictment of how all this shook out that we're so quickly looking to replace http/2. I think moving to quic is a good move but maybe we didn't need an official http/2 standard in the meantime.
        unmole 4y ago
        > is it an aggressive standardization campaign by one interested party Everyone from FB to Microsoft to even Huawei wanted QUIC. It's was not something that only Google was interested in. Hell, the primary author left Google well before the WG was done. > But historically RFCs were built on practice, not the other way around. Right from the early drafts, there have been multiple independent QUIC implementations constantly being tested. There was plenty of working code before there was rough consensus. > standardizing the semantics of http separate from the physical transport What actual semantics of HTTP changed with QUIC?
        deleted 4y ago
- 1vuio0pswjnm7 4y ago
  Given that they have had 34 some odd drafts and continuous errors, with some still not fixed, QUIC is not confidence-inspiring. As an ordinary internet user, the problem I see is that QUIC development is being led by companies, not academics,1 that see the internet first and foremost as an advertising and commerce medium, as would be expected since they are companies pursuing business interests. The issues around those commercial uses are prioritised while issues around ordinary internet user privacy and control are secondary. Certainly QUIC is not the first2 and and will not be the only UDP-based reliable transport protocol but what will be interesting is whether firewall administrators will treat all the alternatives equally. It may be that the corporate-sponsored ones like QUIC are allowed through while ones written by academics or other non-commercial authors are not. 1. Many of the people leading development of the older HTTP versions were academics. 2. See, e.g., CurveCP: https://curvecp.org https://curvecp.org Having played around with CurveCP before QUIC existed, and having already thought CurveCP was amazing, the later commercial effort led by Google has left me underwhelmed.

stormbrew 4y ago

I'm not a huge fan of how spdy and then quic were kinda ramrodded into the HTTP standards process, but realistically I think QUIC is basically the future of connection transport wherever tcp or udp alone are failing at this point. I recently discovered the nQuick proposal to do noise-based connection initiation for peer-to-peer connections and I love it[1]. It's an incredibly versatile protocol. It seems likely that a lot of the issues raised in the OP will be somewhat forced to be resolved due to the aforementioned ramrodding of QUIC into the HTTP3 path, but maybe in the long run the two ideas will co-evolve to the same solution. [1] https://eprint.iacr.org/2019/028.pdf https://eprint.iacr.org/2019/028.pdf

unmole 4y ago
> quic were kinda ramrodded into the HTTP standards process QUIC took 4 years and 34 drafts to get standardized. The final IETF version is significantly different from Google initially came up with. So, no it most definitely was not ramrodded through.
- stormbrew 4y ago
  I didn't say quic itself was -- if quic had been introduced completely independently of http then sure, that's fine. But it was introduced intermingled with making yet another drastic change to a backbone protocol of the internet. Considering HTTP/1.1 stood for over 15 years before http/2 came along (and was a pretty modest improvement over http/1.0 compared to what we're talking about now, so I'm being generous by not saying over 20 years). http/2 had only been promoted to a proposed standard for 3 before http/3 was proposed. That, to me, is a very aggressive process. But again, it's the relationship to http that bothers me, not the standardization process for quic itself.
  - unmole 4y ago
    What's the point of having QUIC if there isn't a protocol that actually uses it? And what would be a better protocol than HTTP? HTTP/2 was a marginal improvement but HTTP/3 and QUIC significantly improve user experience. Especially if the users have jittery networks which is the case for the majority of the world. I don't understand why it would have been a better idea to sit on these improvements for a while before getting them into the hands of users.
    - stormbrew 4y ago
      I don't really see "is it beneficial in the long run" and "is it an aggressive standardization campaign by one interested party" as being the same question. At any rate I also didn't say they shouldn't experiment with using it as an accelerated path for http. I didn't think they shouldn't with spdy either. But historically RFCs were built on practice, not the other way around. If I were the Internet Dictator, I'd be a big fan of standardizing the semantics of http separate from the physical transport and then defining best practices for using alternative transports in the wild, and then eventually standardizing what comes out of that process. To me it's an indictment of how all this shook out that we're so quickly looking to replace http/2. I think moving to quic is a good move but maybe we didn't need an official http/2 standard in the meantime.
      - unmole 4y ago
        > is it an aggressive standardization campaign by one interested party Everyone from FB to Microsoft to even Huawei wanted QUIC. It's was not something that only Google was interested in. Hell, the primary author left Google well before the WG was done. > But historically RFCs were built on practice, not the other way around. Right from the early drafts, there have been multiple independent QUIC implementations constantly being tested. There was plenty of working code before there was rough consensus. > standardizing the semantics of http separate from the physical transport What actual semantics of HTTP changed with QUIC?
        deleted 4y ago
1vuio0pswjnm7 4y ago
Given that they have had 34 some odd drafts and continuous errors, with some still not fixed, QUIC is not confidence-inspiring. As an ordinary internet user, the problem I see is that QUIC development is being led by companies, not academics,1 that see the internet first and foremost as an advertising and commerce medium, as would be expected since they are companies pursuing business interests. The issues around those commercial uses are prioritised while issues around ordinary internet user privacy and control are secondary. Certainly QUIC is not the first2 and and will not be the only UDP-based reliable transport protocol but what will be interesting is whether firewall administrators will treat all the alternatives equally. It may be that the corporate-sponsored ones like QUIC are allowed through while ones written by academics or other non-commercial authors are not. 1. Many of the people leading development of the older HTTP versions were academics. 2. See, e.g., CurveCP: https://curvecp.org https://curvecp.org Having played around with CurveCP before QUIC existed, and having already thought CurveCP was amazing, the later commercial effort led by Google has left me underwhelmed.