Subject: Setting DSCP for IPv6 Neighbor Discovery packets

From: Patrik Lahti <[email-masked]>
Date: Wed, 07 Jul 2010 13:55:17 -0400

Hi,

(I didn't find any previous discussion on this topic, my apologies if 
it's already been discussed and concluded.)

I'm of the opinion that IPv6 Neighbor Discovery packets are important to 
keep the network functioning and perhaps should be classified as network 
or internetwork control packets and be prioritized accordingly.

Currently many implementations send Neighbor Discovery traffic using the 
default (Best Effort, i.e. zero) DSCP value, and e.g. if other higher 
priority traffic (lets say a lot of voice traffic) is competing for 
bandwidth then ND may cease to function correctly potentially leading to 
all sorts of havoc. Hosts can't get addresses, can't detect if they're 
duplicate, can't find default routers, etc. Even if the outage is 
temporary, the user experience may already have suffered.

Yes, ND is only used on the link, and no routers would look at the DSCP 
in ND messages when forwarding. However, the network stack using 
internal QoS mechanisms may experience congestions locally, and link 
level devices may experience congestion too and the DSCP is often mapped 
into link layer QoS mechanisms.

I initially thought all ND messages (RA, RS, NA, NS, Redirect) could use 
the same DSCP. It was suggested to me that maybe the DSCP of ND packets 
should perhaps be copied from the packet which "invoked" the ND message, 
e.g. from the NS that invoked the NA, or from the data packet which 
triggered an NS. And in other cases where there is no direct invokation 
it may be a fixed value depending on what the message is trying to 
achieve, e.g. periodic RAs, or reachability confirmations could carry 
the highest DSCP of all traffic using the cache entry.

What are your thoughts? Can you shed some light on this topic? Does this 
fall into implementation defined behaviour?

PS. I discussed this topic briefly on the NetBSD tech-net list, but 
quickly realized the specs are open for interpretations and I'm hoping 
to clarify that here.
http://mail-index.netbsd.org/tech-net/2010/07/07/msg002209.html

Cheers!
/P

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Fri, 9 Jul 2010 00:40:18 +0200

* Patrik Lahti | 2010-07-07 13:55:17 [-0400]:

>I'm of the opinion that IPv6 Neighbor Discovery packets are important
>to keep the network functioning and perhaps should be classified as
>network or internetwork control packets and be prioritized
>accordingly.

See RFC 4594, section 3

>Currently many implementations send Neighbor Discovery traffic using
>the default (Best Effort, i.e. zero) DSCP value, and e.g. if other
>higher priority traffic (lets say a lot of voice traffic) is
>competing for bandwidth then ND may cease to function correctly
>potentially leading to all sorts of havoc. Hosts can't get addresses,
>can't detect if they're duplicate, can't find default routers, etc.
>Even if the outage is temporary, the user experience may already have
>suffered.
>
>Yes, ND is only used on the link, and no routers would look at the
>DSCP in ND messages when forwarding. However, the network stack using
>level devices may experience congestion too and the DSCP is often
>mapped into link layer QoS mechanisms.
>
>What are your thoughts? Can you shed some light on this topic? Does
>this fall into implementation defined behaviour?

Yes and no. RFC 4594, section 3 talk about Network Control Traffic:

   Network control traffic is defined as packet flows that are essential
   for stable operation of the administered network as well as for
   information that may be exchanged between neighboring networks across
   a peering point where SLAs are in place.  Network control traffic is
   different from user application control (signaling) that may be
   generated by some applications or services.  Network control traffic
   is mostly between routers and network nodes that are used for
   operating, administering, controlling, or managing the network
   segments.  Network Control Traffic may be split into two service
   classes, i.e., Network Control and OAM.

The RFC focus on routing protocols (OSPF, BGP, ISIS, RIP). But your are right,
ND can and should also be treated as network control traffic. You already
mentioned it, the scope of link local traffic is limited but I am aware of some
environments where the network layer DSCP is the basis for link layer queueing
and 802.3p CoS marking.

Concrete example (Linux centric):

tc qdisc add dev eth0.1 root handle 1: prio 
tc filter add dev eth0.1 parent 1:0 protocol all u32 match u32 0 0 action skbedit priority 3

Later on the RFC _recommends_ for network control traffic DSCP marking CS6
(Class Selector 6). And this is the most important fact: it is and should be a
suggestion because quality of service and DiffServ marking is a _operational
requirement_. There can be environments where network control traffic should be
treated as DF (Default Forwarding). Think about low latency trading environment
with several priority levels. You cannot and should not artificial limit the
system by dictate the use of DSCP - the recommendations are sufficient.

Cheers, Hagen

-- 
Hagen Paul Pfeifer <[email-masked]>  ||  http://blog.jauu.net/
Telephone: +49 174 5455209           ||  Key Id: 0x98350C22
Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22

---

From: Patrik Lahti <[email-masked]>
Date: Thu, 15 Jul 2010 11:56:56 -0400

> system by dictate the use of DSCP - the recommendations are sufficient.

Thanks Hagen,

Do I understand correctly then that it's essentially something that 
should be configurable and that there are practical reasons for needing 
to have the ability to configure it?

If so, what is your (and others') opinion on whether it should be 
configurable per ND message type? And/or should DSCP be copied from the 
invoking packet?

Cheers!
/P

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Jul 2010 09:20:15 +1200

On 2010-07-16 03:56, Patrik Lahti wrote:
...
> configurable per ND message type? And/or should DSCP be copied from the

My opinion is that this is 100% an implementation & deployment issue
that doesn't require discussion in 6man as a standards matter, and
possibly not even in v6ops. I suppose it might end up in a v6ops BCP
later, but I wouldn't expect that until there's more operational
experience. Maybe a discussion over on [email-masked]
would be useful?

    Brian

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Fri, 16 Jul 2010 01:32:58 +0200

> experience. Maybe a discussion over on [email-masked]

You are right Brian, but I think the lion share is already discussed - not
sure if there any more discussions required. Patrick?

HGN

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Fri, 16 Jul 2010 01:48:17 +0200

> Thanks Hagen,

My pleasure!

> to have the ability to configure it?

If your or any other environment favor link local traffic by special
egress queuing and/or switching and it is therefore advantageously - why
not! The whole diffserv thing should not overrated. It is a clean and nice
basis to classify packets and it is up to the environment to treat a packet
special or not. The RFCs provides a standardized recommendation to achieve
a consistent view. Not more and not less.

> configurable per ND message type? And/or should DSCP be copied from the 

First question: yes
Seconds question:  this is often a kernel-only-thing and I cannot estimate
the whole impact. So: maybe. ;-)

Cheers, Hagen