Per the previous blog, I introduced DiffServ and some of the driving forces behind it. Another factor that’s gaining more attention in the area of QoS recently is maintaining network availability in the face of worm/DoS attacks. But first, a tad more about DiffServ.
DiffServ (in the IP header) is one way to handle QoS by using packet classification tools inside of routers and layer 3/4 switches. The first three bits of DiffServ (the first three bits of TOS which were precedence bits) are now class selectors that form a 6-bit DiffServ Code Point (DSCP). This allows us to do some pretty cool things like expedited forwarding (go to the front of the queue), assured forwarding (go to the front of the queue but with a drop in precedence if things get really backed up), etc. DiffServ can change as the packet is forwarded.
So how can this help us if our network has worms (ugh) causing DoS?
Such anomalous activity can be recognized as sustained spikes by edge routers. The offending packets can then be re-classified (via DiffServ) to “scavenger class” automatically, allowing them to be aggressively dropped to free up bandwidth for normal applications. (Related note: a hot topic is curbing unwanted traffic on the Internet with a broad scope including DoS attacks).
Conversely, you will probably need to ensure that other non-time critical traffic is not completely shut down by heavy real time traffic activity (many VoIP streams and/or streaming video comes to mind). You will always want to reserve at least some bandwidth for “best effort” delivery for other applications (not to mention network management traffic).
As you can imagine, issues surrounding QoS can be very complex, and what I’ve discussed here is only the tip of the iceberg. Fortunately, if you are a QoS/DiffServ shop, you can use the tools provided by WildPackets to study and verify the behavior of your routing policies as packets traverse your network, using bit-mapped filters and triggers on DiffServ to identify anomalous activity.
I’ll leave you with this thought: What happens where there’s simply not enough end-to-end bandwidth to carry on the nth simultaneous VoIP call despite our best efforts at QoS? As it stands now, the voice quality simply degrades to no end. The industry needs to come up with the equivalent of the fast busy tone like we have today on PSTN networks when circuits are busy.
Now that’s something to keep an ear on.