Google is working on creating a new protocol named QUIC to replace UDP
I'll tell you a dirty little secret of the protocol design.<p>Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs, send window and retransmissions. Guess what? If you don't follow windowing semantics of TCP, then one of two things will happen on saturated links - either TCP will end up with all the bandwidth or you will.<p>So - surprise! - you have no choice but to design a TCP clone.<p>[ EDIT ]<p>That said, there <i>is</i> a fundamental problem with TCP, when it's used for carrying secure connections. Since TCP acts as a pure transport protocol, it has no per-packet authentication and so any connection can be trivially DoS'd with a single fake FIN or RST packet. There are ways to solve this, e.g. by reversing the TCP and security layers and running TCP over ESP-over-UDP or TLS-over-UDP (OpenVPN protocol). This requires either writing a user-space TCP library or doing some nasty tunneling at the kernel level, but even as cumbersome as this is, it's still not a reason enough to re-invent the wheel. Also, if you want compression, it's readily available in TLS or as a part of IPsec stack (IPcomp). If you want FEC, same thing - just add a custom transform to TLS and let the client and server negotiate if to use it or not.<p>I mean, every network programmer invents a protocol or two in his lifetime. It's like a right of passage and it's really not a big deal. Unless it ends up attached to a brand name, in which case it starts attracting snarky remarks like this one :)