4 ms·

>>how much effort have you made to understand the improvements? you show no recognition that the concensus-based ietf working groups are in agreement that this

• rektide 6y ago
  ok I didn't know that this was john nagle. that's intimidating. i'm still highly alarmed, both by John & the general level of discourse going on all throughout this thread. i posted replies to a number of others too. there is wild unsubstantiated & mean-spirited speculation running rampant through this, imo, good news. no one talks to how or why they think this is going to help spy on us, or reduce our ability to block ads, yet it's a very popular & trendy opinion. it seems widely assumed that this is all for bad, and everyone seems to want to believe that mis-information. i find it distressing that the world would be so paranoid & crazy as this. after years of IETF hard work & discussion, after countless engineers work tirelessly to maximize privacy & security, after countless points are raised & tackled, the world greets what we think is a real & significant improvement with disdain, distrust, & belittling. this feels like the kind of easy-to-spread paranoia & madness that is part & parcel to the disinformation that has grown a threat to civil order, a threat to reason. it's too easy to knock things down[1], done so casually, & people seem to want to hear it too much. i realize i haven't been helping, haven't been waging an effective campaign to try to promote a healthier course for us, better discourse, but i want to. i want to not be overwhelmed & saddened by unsupported unreason. touching back to @animats' post: > The real motivation is probably to merge ads into the same stream as the content, i don't see any potential for how this would impact ad-blocking or other security measures on the web. HTTP3 offers no new features or capabilities over HTTP2. existing extensions & tools ought be unaffected. > All that effort to get a tiny improvement. imo QUIC+HTTP3 is a straightforward & sensible simplification over what we had, & was a natural route to enhancing the existing systems. http2 wanted to share a connection, allow out of order serving of requests in a better way than the obsolete & complicated/painful & largely removed http1.1 pipelineing, so servers could start working on upcoming work before finishing the current request. quic has been an attempt to take a lot of the good work already done on http2, & to drive it further down the stack, enabling a) others to use the transport/session layers now distilled into quic for their own uses, and b) radically simplifying the http specification's responsibilities by separating out quic transport/session concerns from http. beyond making http3 much simpler, there are other benefits. a capable replacement for WebSockets is forming via WebTransport[2], and a lot of people are hoping the complex SCTP-based WebRTC stack can be re-designed to use WebTransport/quic, once webtransport advances[3]. overall, the greatest proof that this is a simpler, better, more natural path than what we had comes from a quick look a the QUIC active & related documents[4], where we can see a number of different frontiers of innovation for other ways QUIC might be improved & enhanced, including topics such as multicast, load balancing, unreliable connections, & more: quic is a flexible, interesting, compelling extraction of really neat & interesting http2 technology, & decoupled from http, we are seeing amazing innovation take root & allow all sorts of good frontiers to open. quic is itself a big improvement to what was available for transport & session protocols, and it is throwing open the doors to colossal levels of innovation that were not conceivable before. [1] https://en.wikipedia.org/wiki/Brandolini%27s_law https://en.wikipedia.org/wiki/Brandolini%27s_law [2] https://w3c.github.io/webtransport/ https://w3c.github.io/webtransport/ [3] https://bloggeek.me/who-needs-quic-in-webrtc/ https://bloggeek.me/who-needs-quic-in-webrtc/ [4] https://datatracker.ietf.org/wg/quic/documents/ https://datatracker.ietf.org/wg/quic/documents/
  • Animats 6y ago
    > The real motivation is probably to merge ads into the same stream as the content. I was thinking of Google-hosted content, with Google ads. About 25% of web traffic now comes from Google, although that includes YouTube. Google serves some (most?) ads from "doubleclick.com", which can be blocked at the domain level. But if they slip the ads into the same encrypted connection as the content, it's no longer possible to block them from outside the browser. As for traffic issues, I've seen a few papers where people compare QUIC and TCP.[1][2] But nobody seems to be looking at what QUIC-type traffic is doing to other traffic on the same path. Not that I have, either. You can boost your throughput a bit by being more aggressive about sending packets. If the nodes in the middle are all FIFO queues (the cause of "bufferbloat"), the one who sends the most wins. This creates a perverse incentive and a way to game the results of such comparisons. Fair queuing can help. Still, it's probably a win to speed up all the handshaking involved in setting up a TLS connection. The crypto setup is a big cost for small requests. [1] https://blog.codavel.com/quic-vs-tcptls-and-why-quic-is-not-the-next-big-thing https://blog.codavel.com/quic-vs-tcptls-and-why-quic-is-not-... [2] https://github.com/Shenggan/quic_vs_tcp https://github.com/Shenggan/quic_vs_tcp