| QUIC and http/3 address three problems in my mind: a) multiplexed tcp of http/2 is tcp-in-tcp with its well known problems. tcp over udp is not so problematic b) as a udp protocol, congestion control is user space controlled. There's been some work on congestion control lately, but it's difficult to explore that for client to server transfers with tcp c) path mtu detection in the presence of icmp blackholes is still a mess, in 2021; a udp based protocol puts control of packtization into userland. I think that's fairly factual, so here's the opinion part. a) tcp-in-tcp problems could have been solved by just using tcp. http/2 without multiplexing still gives some benefits (explicit server shutdown indications are a big one for me; binary vs text and compression may help with data length, but framing may not) b) plugable congestion control would make more sense here to me. A certain company behind quic also controls a widely deployed operating system, and could make it happen; although adoption is slow, so it would take longer than switching to quic for their sites. c) turning on path mtu blackhole detection by default on that same company's mobile operating system would help here as well. A certain other mobile OS without a diverse hardware marketplace quickly discovers and responds to lost big packets by sending smaller packets. |