4 ms·
It's so trivial to add ordering to UDP, it's really the right protocol to use here. Subverting TCP leads to all sorts of problems around congestion(which you c
by vvanders 9y ago
It's so trivial to add ordering to UDP, it's really the right protocol to use here.
Subverting TCP leads to all sorts of problems around congestion(which you can no longer filter on because which TCP streams are being non-compliant?) that it just should not be done.
- marcosdumay 9y ago> It's so trivial to add ordering to UDP Specially when compared with creating and using a user space IP protocol like was done here, or adding a new one into the kernel.
- JoeAltmaier 9y agoTCP layer also gives you pacing, congestion control and flow control. Which UDP, you'd have to do yourself?
- JoeAltmaier 9y agoAnd its not totally trivial to reorder UDP. Say you receive packets 1,2,3,5. How long to you wait for '4'? Maybe it was dropped; maybe its coming. Then you get 6,7. Is 4 still out there? You've got 3 packets in your pocket, waiting for 4. That adds up too. TCP gives you some idea of what packets you SHOULD have received, so you can respond better. UDP doesn't have any windowing etc so you have no idea.
- vvanders 9y agoI guess I don't really see the big issue with that. It's not like windowing and congestion control is some kind of black magic. It's spelled out pretty cleanly in the TCP RFC and pretty straight-forward to reimplement. Generally if you're hitting cases where TCP is causing you grief and you need to reach for UDP you've already got enough context to understand your congestion problems/etc. We've been doing this in game-dev for decades, ditto the voip space so it's not like you don't have a wealth of knowledge to draw from if you're really stumped.
- JoeAltmaier 9y agoIf you just use TCP again you haven't done anything. The whole point is to avoid latency. Most folks use some UDP-based protocol package instead of reinventing the wheel. Its not rocket science, but it isn't trivial. Defining your own packets to do all the flow stuff is just work, like any other programming task.
- vvanders 9y agoI don't think I was suggesting using TCP, I was suggesting implementing the features you like from TCP into your stack if you really need them. You can do congestion control without retry, etc. I've built variations of UDP based protocols 4 or 5 different times over my career. I'm literally in the middle of this right now with the radio framing protocol I've been developing. I really think you're making it out to be much harder than it is.
- tonyg 9y agoI was delighted when DCCP appeared: https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Pr... It focuses narrowly on a congestion control protocol, and is intended to be combined which whichever datagram-based protocol you have lying around that might be suffering from congestion issues.
- ramenmeal 9y agoIsn't the pacing and congestion control based on ACK's though? And this is suggesting to ACK everything. I feel like I'm missing something.