when I asked people to explain how UDP works I got a lot of answers to the effect of "it's spray and pray"

but I'm having trouble thinking of examples of UDP-based protocols that actually work in a "spray and pray" way —

* DNS is "send 1 packet, retry if you don't get a reply”
* QUIC is a sophisticated system for streaming data over UDP
* I'd guess that video protocols correct for packet loss
* maybe statsd is a "spray and pray” system?

(please do not reply to this explaining how UDP works)

@b0rk I think you're on the right track here. Statsd is a great example--and as I'm sure you remember, that can make your graphs wrong. There's also the Consul UDP gossip layer--remember when that DDOSed itself? 🤣
@aphyr I don't remember that Consul issue actually, I'll look it up! thanks for the pointer
@b0rk I don't know if we ever did a writeup on that one--I have this possibly mistaken memory that it was something like load + packet loss + an aggressive retry mechanism which caused a storm in the gossip layer. Might have been some kind of nack/flow control message issue too? OTOH Nelson's slides (https://www.slideshare.net/slideshow/operating-consul-as-an-early-adopter/53333600) point to churn in service watches. That might *also* be a flow control issue... @coda, you remember this one?
Operating Consul as an Early Adopter

Operating Consul as an Early Adopter - Download as a PDF or view online for free

SlideShare
@aphyr @b0rk I don’t remember any details, just that consul 0.1 was a rodeo.
@b0rk Another example I use in my classes is videogames! Lots of realtime games spray the state of the world to all clients continuously. You (handwaving here) usually only care about the current positions of players, not where they were earlier. And in fact TCP head of line blocking would amplify latency due to occasional packet loss.