Once the non-TCP protocol has been written, we'll need to make sure it's portable through corporate and ISP firewalls, so we should write an HTTP extension that tunnels the non-TCP protocol over HTTP proxies without using CONNECT, and on port 80. We'll need to patch the proxies and the browsers and the web servers, of course, but it's all in the name of a better, newer protocol that doesn't have the clunky overhead of TCP.
And at some point someone will notice that you can't do ECN with existing UDP implementations, so it'll start all over again but this time assembling the raw IP datagrams in userspace, and then that will have to be moved into the kernel to perform well...
I thought Googles experiments have showed that this is less of an issue that what people generally think. Most networks pass UDP traffic just fine. And most failures occur early phase enabling reasonable fallback policy to TCP
For example, most modern-day commercial firewalls more closely resemble a NAT machine than anything else. All your packets may be changed as they pass through in order to verify their authenticity and integrity once they return. And if the protocol isn't supported, it may not be passed through at all.
If you want to support existing networks, it has to be either TCP or UDP. In order to support next-generation firewalls, you also have to use the OS's tcp/ip stack. In order to support typical commercial network/proxy configuration, you have to use a higher level protocol like HTTP. And this isn't even talking about the "features" of the different protocols and how they're handled.
A replacement for TCP has to be done by a standards body and accepted by vendors, or [at least] half of the world will never be able to use it.
