[potkor]

So like others have pointed out, this is not aiming to replace UDP any more than HTTP is aiming to replace TCP. So it's more like a feature rich TCP replacement, a transport protocol that happens to sit on top of UDP (which is what you have to do unless you want to write a OS driver).

As for impact, depends entirely what applications they plan to deploy it on. WebSockets, peer-to-peer WebRTC and media streaming could benefit from real-time friendly properties (fixing head-of-line blocking and enabling selectively unreliable packets). Hard to see anything significant for traditional web content delivery.

There are many things that you might want from a post-TCP transport protocol. Look at some of the SCTP features for a taste. It has stream multiplexing over the single connection, multipath and dynamic address changes, datagram mode, per-message reliable/unreliable option, to name a few.

SCTP seems to have bombed partly because they were "doing it right", ie getting their own IP protocol number and trying to get it deployed inside OS IP stacks instead of of sitting at application level on top of UDP.

The FEC feature in QUIC sounds a little unorthodox unless it's for multicasting or some control plane function, since at this protocol layer it's considered prudent to be sensitive to congestion when coping with packet loss...