State of QoS peering in Nanog

Sun Apr 3 02:23:45 UTC 2011

In a message written on Sat, Apr 02, 2011 at 07:00:52PM -0400, Jeff Wheeler wrote:
> I don't agree with this.  IMO all DDoS traffic would suddenly be
> marked into the highest priority forwarding class that doesn't have an
> absurdly low policer for the DDoS source's access port, and as a
> result, DDoS would more easily cripple the network, either from
> hitting policers on the higher-priority traffic and killing streaming
> movies/voip/etc, or in the absence of policers, it would more easily
> cause significant packet loss to best-effort traffic.

Agree in part, and disagree in part.

No doubt DDoS programs will try and masquerade as "high priority"
traffic.  This will create a new set of problems, and require some
new solutions.

Let's separate the problem into two parts.  The first is "best
effort" traffic.  Provided the QoS policy only prioritizes a fraction
of the bandwidth (20 to maybe 40%), the impact of a DDoS that came
in prioritized would only be a few percentage points worse than a
standard DDoS.

Today it takes about 10x link speed to make a link "completely
unusable" (although YMMV, and it depends a lot on your traffic mix
and definition of unusable).  Witha  25% priority queue, and the
DDoS hitting it that may drop to 8x.  I think it is both statistically
interesting, but also relatively minor.

The second problem is what happens to priority traffic.  You are
correct that if DDoS traffic can come in prioritized then you only
need fill the priority queue 2x-4x to generate issues (as streaming
traffic is more sensitive), assuming traffic over the limit is not
dropped but rather allowed best effort.  This is likely a lower
threshold than filling the entire link 5x-10x, and thus easier for
the attacker.

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.

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. :(

This is very hard to explain, while people on NANOG might get it 99% of
the network engineers in the world think minimizing packet loss is the
goal.  It is very much an uphill battle to make them understand higher
packet loss often _increases_ end user performance on full links.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110402/f2577ff7/attachment.sig>