Hacker News Reader

Comment by manv1 | Hacker News Reader

It's interesting that everyone (including the author) talks about UDP as a lossy protocol, but it doesn't seem that UDP drops actually occur on a routine basis anywhere. The UDP-based DDOS attacks seem to prove that; if UDP really was being dropped, those DDOS attacks wouldn't be so problematic.

That said, it's an interesting read. TCP is inefficient, but that inefficiency has been patched/masked by hardware solutions.

It's nice to see that someone's still thinking about this this. I remember the days when there were tons of non-IP protocols floating around (IPX, DecNET, AppleTalk, etc). TCP/IP won, which was not an obvious thing at the time.

View on HN

I think re UDP the point regarding it being unreliable is that you have to design your applications to take the unreliability into account, because it does happen even if it may be infrequent: assuming that it is reliable when you can get unreliable behavior will result in correctness issues.

I see UDP more like a low level interface allowing you to build your own on top. Where you decide what packages need to be revived 100% and which one can be dropped. Basically the foundation of your very own TCP with hookers and blackjack.

The new digital television broadcasting system in the US (ATSC 3.0) is exactly this. It's all UDP, but wrapped in another layer which allows multiple virtual streams, and that's all encoded in a CDMA wireless protocol. It's bundled up at the broadcast center, sent out via the big towers, and then unwrapped and decoded on the receiver. The end result is that once the receiver chipset has stripped off the wrapper, the OS of whatever client device is consuming the broadcast just gets regular looking UDP packets filled with MPEG-TS or DASH media streams, plus web pages, ads, games, or whatever. A.k.a. blackjack and hookers. Think of it as a giant one-way WiFi network using just UDP for the packets. It's honestly pretty cool.

> Basically the foundation of your very own TCP with hookers and blackjack.

That’s exactly how the early drafts of the QUIC RFC described it /s

At which point most applications end up reinventing a good chunk of TCP.

Nothing deliberately drops UDP packets, but packets of all sorts get dropped when there's congestion.

Which is why protocols like TCP are built on back pressure - so you don’t keep making the exact same mistake in a tight loop. Happy path behavior doesn’t matter when the worst case or even median case are nonfunctional.

> but it doesn't seem that UDP drops actually occur on a routine basis anywhere.

I have seen code that didn't even handle out of order delivery work well for over a decade in local networks. Even when that broke down it turned out that IP package fragmentation just triggers a slow path in smart switches, so if your packages fit into the networks MTU (with some bytes to spare for VLAN tagging) you still might be able to avoid the problem.

> It's interesting that everyone (including the author) talks about UDP as a lossy protocol, but it doesn't seem that UDP drops actually occur on a routine basis anywhere.

Just to clarify, you are referring to in the datacenter right? They occur in wireless all of the time.

Frame drops are endemic to cloud datacenters. High levels, all the time.

“Lossy” is not the word.

Reliable/unreliable are the words.

Packets can and do get dropped, TCP, UDP or otherwise. It’s just a question of how the protocol behaves when that happens.

Reply on news.ycombinator.com