[139326] in North American Network Operators' Group
Re: State of QoS peering in Nanog
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Sat Apr 2 22:23:55 2011
Date: Sat, 2 Apr 2011 19:23:45 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <AANLkTimL=K+ULtJE2=NQb5-Pjyj=YueJYMUFi-zkVu8Z@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIVAwUBTZfaMbN3O8aJIdTMAQLTJQ//RIHtbo9Txo0jFWtJJMEC6jky3KR7iVX4
zlEcOaQLK4QEtZzFaP/lS8bRGYJsgkOXTy2iZKI0+tkZXJwTmRyP1MJ+qerEA739
pjsLSOUM7xoKrHjrHZi4ouOqf3L48uZaL49YHxr1IN1rl5Q1TJtnEdtyyU4C3jpE
unoWPG8/tJlNhBnN3zGBvSEZTl9z8amt180AymQAReKEgEP1AhhsQ+4l2BaDjzW9
Y9aZ3uQOBc2xcZL/B7qi7VlWFQX+AQCgaZCImYYaItxZ3KNGv1gC8TurDANrvS5r
aAf90M19XPmFVpeGRgqMVivGv3Q29XLA1CZH98ZcP3ssnD7Ulva3zrfccqfDTmOw
486KTGyDMgLaNhAgc/35kaQpxqOYXkTWWVgwnifQY42z4hGN+oGFyw2P4NdAsMNR
GPa5evZB+gY+4znqB0OQ9+Kn/BRR4MwByGJ+uLkLa9fq+Op6Vebi1ZnHLXdpGTUp
Cevs04WsNojsqfH1/ttuLUCtbKvbRBnoRWH3eGXyYVQJfBI86BsdyFGVoBC6YqkT
fr8acddfu+zEV+E16V8XuvpZjVPFk58/sIsyXAsbAmDZhEQXq4SOGHhu95CKKuxh
D0EbBhJnB1VvAXVYgVKJBHbFtZD3JFJf5NRCIiuBjNFJ60OlJRz2lepLCyXqkN1S
xEscgHynfrM=
=JB8s
-----END PGP SIGNATURE-----
--FCuugMFkClbJLl1L--
