State of QoS peering in Nanog

Stefan Fouant sfouant at shortestpathfirst.net
Sun Apr 3 16:50:45 UTC 2011


> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell at ufp.org]
> Sent: Saturday, April 02, 2011 10:24 PM
> 
> But it also only affects priority queue traffic.  I realize I'm making
> a value judgment, but many customers under DDoS would find things
> vastly improved if their video conferencing went down, but everything
> else continued to work (if slowly), compared to today when everything
> goes down.

I'd like to observe that discussion when the Netflix guys come calling on
the support line - "Hey Netflix, yeah you're under attack and your
subscribers can't watch videos at the moment, but the good news is that all
other apps running on our network are currently unaffected". ;>

> In closing, I want to push folks back to the buffer bloat issue though.
> More than once I've been asked to configure QoS on the network to
> support VoIP, Video Conferencing or the like.  These things were
> deployed and failed to work properly.  I went into the network and
> _reduced_ the buffer sizes, and _increased_ packet drops.  Magically
> these applications worked fine, with no QoS.
> 
> Video conferencing can tolerate a 1% packet drop, but can't tolerate a
> 4 second buffer delay.  Many people today who want QoS are actually
> suffering from buffer bloat. :(

Concur 100%.  In my experience, I've gotten much better performance w/
VoIP/Video Conferencing and other delay-intolerant applications when setting
buffer sizes to a temporal value rather than based on a _fixed_ number of
packets.

Stefan Fouant






More information about the NANOG mailing list