3 ms·

Hard to take someone saying what you're saying seriously, when this is given in such a crass and uninformative manner QUIC is a vastly superior transport to TC

Hard to take someone saying what you're saying seriously, when this is given in such a crass and uninformative manner QUIC is a vastly superior transport to TCP in every technical regard. What exactly makes it a "purely corporate needs fulfilling step backwards for human people", if you don't mind adding some context to this extremely vague statement/opinion?

superkuh 6y ago
QUIC is what happens when corporations define standards so their own services can be run cheaper. The transport layer shouldn't be 'aware' of what it is transporting. It shouldn't be a gigantic heap of things, even if those things in the heap sound nice (like encryption baked in). It is already impossible for anyone but Google (or another mega-corp) itself to make a browser that works with "modern" sites. This piles on to that. It is, despite the partial liberation from Google itself by the ietf, still a google attempt to control what HTTP and the web are. Google should not. Protocols should be generic. Layers should layers not just squashed all into one so youtube videos pull up faster on your mobile phone. There's more to the web, and the internet, than fixing mobile latency issues.
- mongol 6y ago
  This sounds like a different variant of the "rampant layering violation" argument that was used against ZFS. It is sometimes healthy to challenge old assumptions. If QUIC turns out better than what we have in every respect that matters "for the end user", as this article is about, what would be the harm?
- Spivak 6y ago
  I really don't get where this argument comes from QUIC is hosted protocol on top of UDP which content-neutral. There's no layering violation since all of QUIC sits at the application layer. And QUIC takes a generic content-neutral payload that you can build on top of. Building TLS into the protocol rather than having a plaintext protocol wrapped in a generic TLS stream isn't that weird -- it's how MySQL does it.
- detaro 6y ago
  Various non-web companies are involved with QUIC work at IETF too, so it has to have some points in the "generic" column, especially since IETF-QUIC separates out the HTTP-replacement layer.
- luizfelberti 6y ago
  So nothing but FUD and ignorance, as expected... If you wanna get angry at Google, get angry at removing URLs from Chrome, not at the good things that they do. > QUIC is what happens when corporations define standards so their own services can be run cheaper 1) Google is not the only one who would be able to run their services cheaper. That is as plain a fact as it could be. Do you think Google is the only company who needs to serve massive amounts of content? In what way is energy and computation efficiency "harming" the internet? > The transport layer shouldn't be "aware" of what it is transporting 2) In what way is QUIC "aware" of what it's transporting? > It shouldn't be a gigantic heap of things 3) QUIC is not a "gigantic heap of things" any more than TLS or SCTP is. It is an L7 protocol hosted on UDP, just like TLS is an L7 protocol hosted on TCP. > It is already impossible for anyone but Google (or another mega-corp) itself to make a browser that works with "modern" sites. This piles on to that 4) This has nothing to do with browsers, and QUIC has nothing that relates exclusively to browsers. Also, the idea that competing in the browser space is will be harder because you need to implement a new transport is laughable. Browser complexity derives from HTML/CSS/WebApps/etc, and QUIC is not only insignificant by comparison, but also a much less volatile feature that wont need to be "evolving" all of the time. > Protocols should be generic 5) QUIC is absolutely, 100% generic? I'm not sure where you're getting the idea that it isn't from... > Layers should be layers 6) Except when the layers are horribly misplaced of course; then you get into the situation we're in with TCP where we have hard-coded definitions for how control flow will work during a given session, what the session is, how you always need a new handshake to start a new one even if on the same host, and then you need to work around all this bullshit by starting a crapton of TCP connections to multiplex streams like HTTP/1.1 does... 7) In what way is QUIC not a layer? 8) That is a horrible argument. Nothing is keeping the IETF from standardizing QUIC at the same level as UDP/TCP/SCTP, you just have to look at IPv6 and SCTP's adoption to understand what happens when you try to change a protocol that deep in the stack. > There's more to the web, and the internet, than fixing mobile latency issues 9) Sure... If you ignore that unlike when TCP was standardized, mobile devices represent 50% of all publicly routed internet traffic, and that all of these devices are dropping packets, triggering retransmissions, and congesting the network for everyone (including non-mobile devices), then there is no probelm at all! That is also known as the tactic 5 year olds use when faced with a problem: closing their eyes and pretending it doesn't exist. 10) I'm not sure where you got the impression that QUIC only brings benefits to mobile latency, but that is also patently false

superkuh 6y ago

QUIC is what happens when corporations define standards so their own services can be run cheaper. The transport layer shouldn't be 'aware' of what it is transporting. It shouldn't be a gigantic heap of things, even if those things in the heap sound nice (like encryption baked in). It is already impossible for anyone but Google (or another mega-corp) itself to make a browser that works with "modern" sites. This piles on to that. It is, despite the partial liberation from Google itself by the ietf, still a google attempt to control what HTTP and the web are. Google should not. Protocols should be generic. Layers should layers not just squashed all into one so youtube videos pull up faster on your mobile phone. There's more to the web, and the internet, than fixing mobile latency issues.

mongol 6y ago
This sounds like a different variant of the "rampant layering violation" argument that was used against ZFS. It is sometimes healthy to challenge old assumptions. If QUIC turns out better than what we have in every respect that matters "for the end user", as this article is about, what would be the harm?
Spivak 6y ago
I really don't get where this argument comes from QUIC is hosted protocol on top of UDP which content-neutral. There's no layering violation since all of QUIC sits at the application layer. And QUIC takes a generic content-neutral payload that you can build on top of. Building TLS into the protocol rather than having a plaintext protocol wrapped in a generic TLS stream isn't that weird -- it's how MySQL does it.
detaro 6y ago
Various non-web companies are involved with QUIC work at IETF too, so it has to have some points in the "generic" column, especially since IETF-QUIC separates out the HTTP-replacement layer.
luizfelberti 6y ago
So nothing but FUD and ignorance, as expected... If you wanna get angry at Google, get angry at removing URLs from Chrome, not at the good things that they do. > QUIC is what happens when corporations define standards so their own services can be run cheaper 1) Google is not the only one who would be able to run their services cheaper. That is as plain a fact as it could be. Do you think Google is the only company who needs to serve massive amounts of content? In what way is energy and computation efficiency "harming" the internet? > The transport layer shouldn't be "aware" of what it is transporting 2) In what way is QUIC "aware" of what it's transporting? > It shouldn't be a gigantic heap of things 3) QUIC is not a "gigantic heap of things" any more than TLS or SCTP is. It is an L7 protocol hosted on UDP, just like TLS is an L7 protocol hosted on TCP. > It is already impossible for anyone but Google (or another mega-corp) itself to make a browser that works with "modern" sites. This piles on to that 4) This has nothing to do with browsers, and QUIC has nothing that relates exclusively to browsers. Also, the idea that competing in the browser space is will be harder because you need to implement a new transport is laughable. Browser complexity derives from HTML/CSS/WebApps/etc, and QUIC is not only insignificant by comparison, but also a much less volatile feature that wont need to be "evolving" all of the time. > Protocols should be generic 5) QUIC is absolutely, 100% generic? I'm not sure where you're getting the idea that it isn't from... > Layers should be layers 6) Except when the layers are horribly misplaced of course; then you get into the situation we're in with TCP where we have hard-coded definitions for how control flow will work during a given session, what the session is, how you always need a new handshake to start a new one even if on the same host, and then you need to work around all this bullshit by starting a crapton of TCP connections to multiplex streams like HTTP/1.1 does... 7) In what way is QUIC not a layer? 8) That is a horrible argument. Nothing is keeping the IETF from standardizing QUIC at the same level as UDP/TCP/SCTP, you just have to look at IPv6 and SCTP's adoption to understand what happens when you try to change a protocol that deep in the stack. > There's more to the web, and the internet, than fixing mobile latency issues 9) Sure... If you ignore that unlike when TCP was standardized, mobile devices represent 50% of all publicly routed internet traffic, and that all of these devices are dropping packets, triggering retransmissions, and congesting the network for everyone (including non-mobile devices), then there is no probelm at all! That is also known as the tactic 5 year olds use when faced with a problem: closing their eyes and pretending it doesn't exist. 10) I'm not sure where you got the impression that QUIC only brings benefits to mobile latency, but that is also patently false