> There is nothing of the original design grandiosity of the first batch of internet protocols here. I'd be interested to know how you feel TCP and QUIC differ

> There is nothing of the original design grandiosity of the first batch of internet protocols here. I'd be interested to know how you feel TCP and QUIC differ in this regard. It seems to me that they're both reasonably similar protocols that design for slightly different things and make different tradeoffs (reliable single-stream transfer vs reliable multi-stream transfer, ip and port-based endpoints vs abstract connection ids, etc). I guess you could see the integration of encryption to be an ugly layering violation, but IIUC the primary driver for that decision is less performance and more to prevent ossification by ensuring as much protocol information as possible is inaccessible to middleware. I'm less enthused about HTTP/3 - I would've liked to see a simpler, "QUIC-ified" version of HTTP/1.1 done first (ie. basically just normal HTTP except with one request per stream), but I guess it's a hard sell to roll back from HTTP/2's efficiencies, and HTTP/2 itself is unsuitable for QUIC since it duplicates much of its functionality. I also want to see QUIC used for more protocols, especially those that (like HTTP/2) already had some level of stream multiplexing built in (AMQP comes to mind here).