[AusNOG] DSCP on internet services

[Glen Turner]

AARNet marks DSCP=BE (and doesn't touch ECN) on incoming traffic from
non-QoS capable customers and peers. If we then have reason to believe
that the traffic may be malicious (eg, all ICMP Echo and Echo Reply) we
mark that traffic to DSCP=AF1 ("Scavenger" or "worst effort" service).
The Scavenger service is limited -- when under congestion -- to 1% of
the capacity of any link it crosses. Of course, if Scavenger isn't using
that 1%, then that capacity is available to BE traffic.

The implication is that "ping" shows the worst-case performance of the
network. Live with it and don't use ping across ISPs for STONITH.

For QoS-capable peers we accept DSCP-marked traffic for voice and
video up to a pre-agreed limit on a single leaky bucket policer
(typically 3Mbps and 30Mbps).  Traffic exceeding the policing is
dropped or re-marked into Scavenger, whichever we prefer (in reality,
depending upon the capabilities of the router). For outgoing traffic,
we queue voice at 3Mbps to the customer (ie, an E1) or 10% of a backbone
link; we queue video at 30Mbps to the customer or 20% of a backbone link.
Again, if the capacity isn't used then it is available to BE traffic.

We also run a Control DSCP which is not customer reachable. It gets
10% of any link when under congestion. Routing protocols, management
SSH, and management SNMP (as opposed to customer SSH and SNMP) run
in that class. Our outgoing router control traffic is in that class,
the incoming traffic really depends on the QoS policy of the other
peer.

Outgoing queues mark ECN where the equipment is capable. In that
case we randomly mark ECN starting at 1/3rd the queue depth. Our
experiments show this gives enough delay for a RTT and thus for
the ECN to be acted upon.

Talking with large US ISPs, this seems a pretty typical approach;
with the exception that AARNet doesn't do gold/silver/bronze. That
approach really got unattractive for me after SQL Slammer, a worm
that propogated primarily inside customer networks, flipping the
expected threat scenario for worms. After that we didn't want to
offer VPNs a Gold class, and then see the VPNs stomp all over Internet
BE traffic with the next SQL Slammer. We'd prefer VPNs took a DWDM
service instead (which would also lower customer equipment costs in
those remote sites), or were just IPSec customer-initiated BE tunnels.



In terms of "best practice" you should:
  -  Treat all incoming traffic as BE or worse
  -  Until that traffic has passed admission control
     (eg, policing between customers that have some trust,
      or a H.323 proxy or a SIP session border controller
      where trust is less)
  -  Distinguish router-initiated control traffic, and
     queue it with some priority over customer traffic.
     This prevents high levels of traffic on links from
     dropping control traffic and black-holing.

Whether you should classify traffic at each node and pass
the DSCP setting along unaltered, or classify the traffic
at the edge and re-mark it (excluding ECN, which isn't really
part of the DSCP) is entirely a matter for your network
design. There are arguments either way (since AARNet offers
a comprehensive QoS service I felt that no information was
lost for further ISPs by us re-marking).

   - If you do re-mark, try to negotiate QoS with customers
     and peers. If a peer has marked traffic as "worst effort"
     then I don't re-map that into my "best effort" class, I
     put it in my "worst effort" class.

     But if a peer says it's voice, then I want to hear about
     their admission control before I believe them -- if there
     is no admission control, then it gets re-marked to BE.
     That way a DoS attack at that peer which cycles through
     DSCP markings won't hammer our voice service.

-- 
  Glen Turner   <http://www.gdt.id.au/~gdt/>