5 ms·

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 con

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
        [deleted]
      - simmervigor 4y ago
        > 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. This is what the IETF has been doing for several years already as part of the core HTTP specification rewrite. Namely, see the HTTP Semantics document https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-19.html https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics... Semantics are common, how those map to specific transport - how it looks on the wire - is then the job of each individual HTTP version. It reads like you're overlooking the act of standardization in improving the definition of a protocol. Experimentation is good but often only focuses on a limited set of use cases, deployments, or implementations. Standardization is great for interoperability across a more diverse set of all those three. This typically yields protocols that are more generally applicable for a wider population of the Internet. Google QUIC was focused on an HTTP use case and thatbran through the entire design. Through the IETF process, the design evolved to be a far more generic transport with rich extensibility and modularity.
  - aseipp 4y ago
    You've got it backwards. The final problem with HTTP/2 couldn't be solved by the application layer protocol alone, so "intermingling" is a "not-even-wrong" complaint -- if you transported a large JPEG and an HTML page over the network in an HTTP/2 stream, a lost packet in the jpeg file would cause the html stream to potentially stall until it was corrected and finished, even though you can load both concurrently. This effectively causes head-of-line blocking on what should be a concurrent system. So a primary attraction of HTTP/2 is effectively defeated and possibly even made worse; it is a behavior instituted by TCP, there's nothing you can solve it with. QUIC was "intermingled" because it exactly solved this problem at the transport layer, the only place it can be solved. They couldn't just introduce any random thing, and no other protocol existed, so they ratified QUIC independently as its own protocol and applied it to HTTP/3 at the same time. They had to introduce a new standardized transport if the hope was to solve the HOL blocking issue. If you "dis-entangled" it you'd just have HTTP/2. The new transport protocol is the defining characteristic. Furthermore it all would have been pointless to define QUIC as a standard without actually applying it in practice, in anger, to real workloads. Which is exactly what multiple stakeholders in the process did throughout the multi-year ratification process. What are they going to do, define QUIC, sit on their thumbs for 5 years and cross their fingers hoping someone else tries it? There are other factors like most of the involved stakeholders had previous experience watching with other attempted standards in similar veins like TCP Fast Open die on the vine. That also influenced decisions like using UDP for QUIC's transport (and the ever present discussions about middleboxes.) Actual experience indicates most low-level protocols have ossified badly or are handled very poorly, including TCP and UDP except most things can handle those, so moving the transport layer into the application stack is seen as providing actual agility needed to respond to issues like the HOL blocking issue. That's how they revised the protocol several dozen times over the years; applications are actually fairly agile. Now you could argue these people should have discovered that issue when designing HTTP/2, but "Why didn't this thing get discovered and found out?" is always a weird complaint. Why would you expect everything to be found out early? I just can't answer that complaint honestly. Weirder things have happened than "Some engineers missed something." Many people seem to hold some unwritten belief that if a protocol is defined as, say, an application layer protocol at one point, then it can never ever redefine its parameters to be anything beyond that. It can never become a transport protocol, for example, or have the two be mandated together, despite decades of experience suggesting that might be a fruitful path for many technical reasons. But there's no random rules of the universe defining what a network protocol looks like. It can be whatever we want it to be. Humans define this, there isn't like a book of 10 commandments out there written by God. There is also no necessary indication that HTTP 1.1 sticking around for so long versus HTTP/2 necessarily meant it was the best among all options, by the way. We abused it a lot for many things. Being around for so long could also mean we were just bad at enacting change; certainly browser monocultures have made change easier for better and worse, on that note. But the whole HTTP/2 and HTTP/3 process has been about 13 years on its own if you count it as starting with SPDY. It's not like there's 200 years of precedent for how long it should take.
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.

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
        [deleted]
    - simmervigor 4y ago
      > 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. This is what the IETF has been doing for several years already as part of the core HTTP specification rewrite. Namely, see the HTTP Semantics document https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-19.html https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics... Semantics are common, how those map to specific transport - how it looks on the wire - is then the job of each individual HTTP version. It reads like you're overlooking the act of standardization in improving the definition of a protocol. Experimentation is good but often only focuses on a limited set of use cases, deployments, or implementations. Standardization is great for interoperability across a more diverse set of all those three. This typically yields protocols that are more generally applicable for a wider population of the Internet. Google QUIC was focused on an HTTP use case and thatbran through the entire design. Through the IETF process, the design evolved to be a far more generic transport with rich extensibility and modularity.
- aseipp 4y ago
  You've got it backwards. The final problem with HTTP/2 couldn't be solved by the application layer protocol alone, so "intermingling" is a "not-even-wrong" complaint -- if you transported a large JPEG and an HTML page over the network in an HTTP/2 stream, a lost packet in the jpeg file would cause the html stream to potentially stall until it was corrected and finished, even though you can load both concurrently. This effectively causes head-of-line blocking on what should be a concurrent system. So a primary attraction of HTTP/2 is effectively defeated and possibly even made worse; it is a behavior instituted by TCP, there's nothing you can solve it with. QUIC was "intermingled" because it exactly solved this problem at the transport layer, the only place it can be solved. They couldn't just introduce any random thing, and no other protocol existed, so they ratified QUIC independently as its own protocol and applied it to HTTP/3 at the same time. They had to introduce a new standardized transport if the hope was to solve the HOL blocking issue. If you "dis-entangled" it you'd just have HTTP/2. The new transport protocol is the defining characteristic. Furthermore it all would have been pointless to define QUIC as a standard without actually applying it in practice, in anger, to real workloads. Which is exactly what multiple stakeholders in the process did throughout the multi-year ratification process. What are they going to do, define QUIC, sit on their thumbs for 5 years and cross their fingers hoping someone else tries it? There are other factors like most of the involved stakeholders had previous experience watching with other attempted standards in similar veins like TCP Fast Open die on the vine. That also influenced decisions like using UDP for QUIC's transport (and the ever present discussions about middleboxes.) Actual experience indicates most low-level protocols have ossified badly or are handled very poorly, including TCP and UDP except most things can handle those, so moving the transport layer into the application stack is seen as providing actual agility needed to respond to issues like the HOL blocking issue. That's how they revised the protocol several dozen times over the years; applications are actually fairly agile. Now you could argue these people should have discovered that issue when designing HTTP/2, but "Why didn't this thing get discovered and found out?" is always a weird complaint. Why would you expect everything to be found out early? I just can't answer that complaint honestly. Weirder things have happened than "Some engineers missed something." Many people seem to hold some unwritten belief that if a protocol is defined as, say, an application layer protocol at one point, then it can never ever redefine its parameters to be anything beyond that. It can never become a transport protocol, for example, or have the two be mandated together, despite decades of experience suggesting that might be a fruitful path for many technical reasons. But there's no random rules of the universe defining what a network protocol looks like. It can be whatever we want it to be. Humans define this, there isn't like a book of 10 commandments out there written by God. There is also no necessary indication that HTTP 1.1 sticking around for so long versus HTTP/2 necessarily meant it was the best among all options, by the way. We abused it a lot for many things. Being around for so long could also mean we were just bad at enacting change; certainly browser monocultures have made change easier for better and worse, on that note. But the whole HTTP/2 and HTTP/3 process has been about 13 years on its own if you count it as starting with SPDY. It's not like there's 200 years of precedent for how long it should take.

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.