Hacker News new | past | comments | ask | show | jobs | submit login

You're right in that UDP will let you send the most updated data without requiring everything to be sent. My main issue was that UDP does not give you lower latency. TCP algorithms are extremely aggressive to the point I doubt you could get more recent packets on the wire with UDP.

The problem is, the OS throws everything into the same buffer, and unless you're clairvoyant you won't be able to skip sending old packets into the buffer until it's too late. Basically by the time you know the data is outdated it's already on the way to the NIC buffer and you can't stop it, making TCP and UDP equal in this regard




You're only considering the case when no packets are lost.

Once TCP drops a packet, data sits in the receiving buffer getting older and older instead of being delivered to the program.


It's way more rediculous than you think. OS network stacks try to do the reasonable thing in most cases if possible. In the case of Linux TCP Vegas is very unlikely to drop any packet since the main algorithm is RTT based not drop.

Red and hopefully codel can combat buffer bloat to some point but in the end all packets go to the same place


I see packet loss and spurious resends (lost acks) all the time on WiFi in certain locales. You are massively underplaying packet loss imo.


I think he meant the situation where the network drops a TCP segment, leading to head-of-line blocking.


Waiting for retransmission of a lost segment in front of you in the queue is massive latency.


TCP does head of line blocking so your entire argument is just wrong. TCP by design cannot give you the latency guarantees that UDP can.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: