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.

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