These use cases spring to my mind: real-time data and multi-player action games, perhaps even streaming media.
TCP and HTTP are less than ideal transports when it comes to real time data. In case of a network error, TCP retransmits the lost data but in a real-time environment, the data is already old and therefore next to useless. Real time action games (like quake) favor udp over tcp.
Some questions: Why replace UDP? Why not work on top of UDP? There must be a reason for this. What about multicast?
UDP doesn't have any guarantee that packet is received. If you stream video that can handle few lost packet it is ok, but if you need reliability than you need TCP. So, it's kind of programmer decision what to use. In reality there should be protocol that is lightweight and somewhere in between TCP and UDP (from personal experience). I haven't read anything about this new google protocol, but i'm not sure if they are trying to do that. Well, maybe i should go and read it >:-)
TCP and HTTP are less than ideal transports when it comes to real time data. In case of a network error, TCP retransmits the lost data but in a real-time environment, the data is already old and therefore next to useless. Real time action games (like quake) favor udp over tcp.
Some questions: Why replace UDP? Why not work on top of UDP? There must be a reason for this. What about multicast?