4 ms·

Her category 'lost in transit' is perhaps the biggest cause of UDP drops. No matter how big your buffers on the send/receive side, if an intermediary carrier d

by chair6 10y ago

Her category 'lost in transit' is perhaps the biggest cause of UDP drops. No matter how big your buffers on the send/receive side, if an intermediary carrier decides UDP is not important or a D/DoS threat to their network, bye bye packet... or in some cases of rate-limiting, see you in a while perhaps. A few rabbit-holes to dive down: https://www.us-cert.gov/ncas/alerts/TA14-017A https://www.us-cert.gov/ncas/alerts/TA14-017A http://www.christian-rossow.de/articles/Amplification_DDoS.php http://www.christian-rossow.de/articles/Amplification_DDoS.p... https://tools.ietf.org/id/draft-byrne-opsec-udp-advisory-00.txt https://tools.ietf.org/id/draft-byrne-opsec-udp-advisory-00.... https://datatracker.ietf.org/wg/taps/charter/ https://datatracker.ietf.org/wg/taps/charter/

JoeAltmaier 10y ago
The app can be at fault too. Some traffic is bursty (video frames, large files, images) and some client stacks have tragically small IP buffers (as little as 128K in some OSs). Apps must be prepared to read to exhaustion without pausing to process in those situations, then process once the buffer-storm is over.
- advisedwang 10y ago
  Yep, I once saw a case with syslog over UDP with thousands of servers reporting to one central logging point. All the servers ran a command at the same time, and logged a message within ms of each other. The flood of UDP messages caused completely predictable input buffer overflow.
  - jmcnulty 10y ago
    Otherwise called the stampeding herd effect. The way to address this is to introduce a random sleep on the remote servers before the command executes to spread the load.