[zests]

I am a networking novice but the fact that my networking book (TCP/IP illustrated) has one chapter on UDP and several on TCP speaks (literal) volumes.

My entirely uninformed opinion is that if its possible to do everything TCP does over UDP we should do so just based on the fact that it is a simpler protocol. This means that broadly speaking I think the QUIC protocol is an improvement. (Whether or not its worth implementing the change I have no opinion on.)

Obviously this is a very naive understanding and I welcome others telling me where my simple model breaks down. Understandably the complexity is not removed and is only pushed up the protocol stack but I would argue that the higher complexity belongs at the application layer rather than the transport layer.

[AnotherGoodName]

> My entirely uninformed opinion is that if its possible to do everything TCP does over UDP we should do so just based on the fact that it is a simpler protocol.

UDP is actually a nightmare precisely because it is so simple. There's nothing more than incoming data to your network on a particular socket. Where should your router send it after NAT? There are so many RFCs and articles on UDP NAT traversal and you'll find it's never as reliable as plain old TCP. Good luck with UDP hole punching when 2 clients pick the same port to receive data (so many games do this and if you find yourself and someone on your local network can't play this same game online at the same time this is why).

Oh and if you actually do need packet ordering you'll now be wasting time re-implementing what is essentially TCP within UDP. The major advantage of UDP is it gives the option of not caring about packet ordering which is good but only for very very specific use cases (lossy voice/video communication and games).

The article also talks about how TCP doesn't know the speed of your network and has a slow ramp up. You know what UDP does? It sends out data as fast as you tell it to and then if that's too much for the network it's simply dropped. TCP stops you sending to much.

That's just a start too.

So unsurprisingly TCP has complexity. If you do go down the path of UDP which can only ever be justified due to a very specific need you'll need all that TCP knowledge and more as you'll inevitably have to re-implement much of what TCP does.

[klodolph]

Packets aren’t created equal. Don’t think of a network as just a medium which lets you send packets from point A to point B. It’s a reasonable simplification but it’s not accurate!

Routers read the contents of TCP packets to figure out the state of the TCP connection, and then make decisions based on the state of that connection. With UDP that doesn’t work. This makes a HUGE difference for NAT. With UDP, there’s no connection and no state, so at best a router might guess correctly using some loose heuristics, but at worst the router will just drop your UDP packets on the floor.

[wmf]

TCP/IP illustrated has one chapter on UDP and several on TCP

Because TCP does far more than UDP.

if it's possible to do everything TCP does over UDP we should do so just based on the fact that it is a simpler protocol

The complexity of TCP is mostly needed, so reimplementing the same complexity yourself on top of UDP doesn't really gain you anything. The overall result isn't simpler.

[johannes1234321]

> My entirely uninformed opinion is that if its possible to do everything TCP does over UDP we should do so just based on the fact that it is a simpler protocol

Everything which can be done with a truck can be done with a horse wagon.

Yeah, that analogy doesn't fully work, but QUIC is no perove of UDP being the right tool, QUIC is an iteration of TCP. Looking at some shortcomings of TCP (in the view of it's creators) and trying to fix those. If it is successful the chapters in your book will be as long as those of TCP and probably even lots of the content will be similat. It will do some form of connection negotiation (even more complex than TCP as it enforces TLS, which in TCP is fully in the application layer) and flow control. Basing it on top of UDP instead of using IP directly is not due to UDP being best, but routers, firewalls and operating systems being able to handle it. A new IP packet type would need lots of work by everybody.

[the8472]

If you do everything over UDP then you have to reinvent a lot of what TCP brings to the table, in every single application. The most critical part is congestion control. And people are bound to reinvent or reimplement those parts poorly because most high level programming language standard libraries don't expose all the ancillary socket data you would need to get the header data (e.g. ECN flags or MTU). With all that complexity you will be back to worth several books, but this time you don't just need to be able to use it but also maintain it.

For many usecases TCP works well and you should avoid adding another dependency.