Hacker News Reader

Frankly, I am a bit disappointed with the article. I fail to follow the argument that an encrypted header makes it easier to adopt HTTP/3 & QUIC because middleboxes cannot see the header. With HTTP/1.1 & TCP, the middleboxes should not be changing the TCP packets anyway, no? Also, the author does not point out that QUIC builds on UDP instead of directly building on IP like TCP does.

View on HN

Even though they arguably shouldn't, some middleboxes assume that protocols don't change. They have made it hard for protocols such as TCP and TLS to evolve without breaking things.

Similarly, middleboxes have made it unviable to deploy protocols that aren't TCP or UDP based.

https://en.wikipedia.org/wiki/Protocol_ossification

I did not know that protocol ossification was a such a thing. Thanks for the link, it's an interesting article.

It says that middleboxes near the edge are more likely to be the cause of ossification. Are there any stats about that? Such as some manufacturers or software companies "infringing" on the end-to-end principle more often than others?

Not sure about stats but if you hang out in networking forums, you'll see netops complaining about bad implementations of protocols in their networking gear forever. This has been a huge problem in several protocols, everything from SCTP to IPSec to UDP RTSP.

Reply on news.ycombinator.com