Setting DSCP for IPv6 Neighbor Discovery packets

[Patrik Lahti]

Hi,

I'm of the opinion that IPv6 Neighbor Discovery packets are network
control packets and hence they should be prioritized accordingly. In
fact, network control should probably be the highest priority.

Currently Neighbor Discovery traffic is sent using the default (Best
Effort, i.e. zero) DSCP value, and e.g. if other higher traffic (lets
say a lot of voice traffic) is competing for bandwidth then it may cease
to function correctly potentially leading to all sorts of havoc.

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

What are your thoughts? Shouldn't be too hard to change right? I'm
thinking it's simply a matter of a one line change in the various
nd6_*_output() routines and setting IPV6_TCLASS in rtadvd/rtsold.

Should it be sysctl'able or hard coded to a particular value? What
default? I'd lean towards 0xe0 at the moment, as it's compatible with IP
Precedence usage and IIRC I think I've seen packet traces where it was
used as well.

PS. The same could be said about ARP, but since ARP rides directly on
Ethernet, it's kind of a different topic.

Cheers!
/P

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

In fact, network control should probably be the highest priority.

Oddly enough, it is, in the original ToS spec - page 12 of RFC 791. :)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Tue, 06 Jul 2010 20:37:22 -0400
From: Patrik Lahti <***@qnx.com>
Message-ID: <***@qnx.com>

| I'm of the opinion that IPv6 Neighbor Discovery packets are network
| control packets

I disagree. With the possible exception of RA's (I'm not sure if your
use of the "IPv6 Neighbor Discovery" term includes everything, or just NS/NA
the elements of the part of ND that is ARP like), and just perhaps unsolicited
NA's after an address change, there's nothing about ND that is network control.

Network control is about keeping the network working - which could include
stuff needed for loop detection (were anything of the kind needed), and
certainly, I think, RA's that advertise prefixes.

On the other hand, NS/NA just allow hosts to use the network - how important
that is depends entirely upon how important the communications are, which
will vary from host to host, and with each of its peers, and even from time
to time depending upon why it is sending packets.

The traffic class of an NS should be the same as the highest traffic class
of the packets that are to be communicated - which in practice, means the same
as the packet that triggered the NS, unless ND was already in progress with
a higher traffic class. A reply NA should have the same class as the ND
that requested it. "Refresh ND's" (if we generate such things) can be any
random (fairly low) class. NS used for DAD should be nothing at all.
RS should also be 0. RA (and perhaps an unsolicited NA, that one would
take more thought) might be worthy of being considered network control.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Patrik Lahti]

Post by Robert Elz
Date: Tue, 06 Jul 2010 20:37:22 -0400
| I'm of the opinion that IPv6 Neighbor Discovery packets are network
| control packets
I disagree. With the possible exception of RA's (I'm not sure if your
use of the "IPv6 Neighbor Discovery" term includes everything, or just NS/NA
the elements of the part of ND that is ARP like), and just perhaps unsolicited
NA's after an address change, there's nothing about ND that is network control.
Network control is about keeping the network working - which could include
stuff needed for loop detection (were anything of the kind needed), and
certainly, I think, RA's that advertise prefixes.
On the other hand, NS/NA just allow hosts to use the network - how important
that is depends entirely upon how important the communications are, which
will vary from host to host, and with each of its peers, and even from time
to time depending upon why it is sending packets.
The traffic class of an NS should be the same as the highest traffic class
of the packets that are to be communicated - which in practice, means the same
as the packet that triggered the NS, unless ND was already in progress with
a higher traffic class. A reply NA should have the same class as the ND
that requested it. "Refresh ND's" (if we generate such things) can be any
random (fairly low) class. NS used for DAD should be nothing at all.
RS should also be 0. RA (and perhaps an unsolicited NA, that one would
take more thought) might be worthy of being considered network control.

Some very good points Robert,

Maybe I should ask this on an IETF list?

I was thinking of ND in the broadest sense, including RAs, NS/NA for
neighbor resolution, Duplicate Address Detection, reachability, address
change, redirects, all of it.

But I think you're right that the class should depend on what the ND
message is trying to accomplish.

Here are some further thoughts on what you suggested:

Since RAs are critical for autoconfiguration they should be
network/internetwork control. I include RAs without prefixes in that too
because hosts need to receive those too for autoconfiguration the
default router. However, I think probably DAD should be included there
too, because it also keeps the network working. If DADs get lost then
that may result in duplicate addresses.

Responses should probably use the DSCP from the packet they respond to.
Except RA in response to RS, they should probably still be prioritized
as above since they're sometimes responses to many RSs.

And when the ND protocol is invoked as a result of another packet it
should probably reflect the same DSCP as the invoking packet, i.e. NS
for neighbor resolution, redirects, and RSs. If RSs are too low priority
then hosts will have a hard time "coming on to" the network because they
don't get an address or a default router. Yes, they probably
"eventually" get an RS through or receive the prioritized periodic RAs,
but again user experience is already affected if plugging into the
network doesn't get you network connectivity within reasonable time.

The IPv4 Router Requirements RFC says ICMPv4 should copy the ToS from
the invoking packet, so this is hint in that direction.

Unsolicited ND used for reachability checks should probably fall into
the same category of using the DSCP of the invoking traffic, although it
may add complexity to have to remember the highest priority of all
traffic that used the ND cache entry.

OTOH, one could argue it is simpler to just set all ND traffic to the
same (sysctl'able) DSCP.

I guess it's really open to interpretation whether ND is network or
internetwork control, whether it's only partly one of those, and/or
should inherit the DSCP of invoking packet. The RFCs have mentioned
routing is. Is it a stretch to say ND is routing or not...? It after all
partly about finding the packet's way in the "neighborhood" (the link)
and also about nodes getting their addresses which is pretty fundamental.

Cheers!
/P

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Patrik Lahti
I'm of the opinion that IPv6 Neighbor Discovery packets are network
control packets and hence they should be prioritized accordingly. In
fact, network control should probably be the highest priority.

At most they are internetwork control (old tos 6); network control is
about the layer used by the internetworking layer.

Post by Patrik Lahti
Currently Neighbor Discovery traffic is sent using the default (Best
Effort, i.e. zero) DSCP value, and e.g. if other higher traffic (lets
say a lot of voice traffic) is competing for bandwidth then it may
cease to function correctly potentially leading to all sorts of havoc.

What do the standards say? What do other operating systems do?

Post by Patrik Lahti
Yes, ND is only used on the link, and no routers would look at the
DSCP in ND messages. However, the network stack, e.g. using ALTQ may
experience congestions locally, and link level devices (e.g. switches)
may experience congestion too and the DSCP is often mapped into link
layer QoS mechanisms.

That's fair.

Post by Patrik Lahti
What are your thoughts? Shouldn't be too hard to change right? I'm
thinking it's simply a matter of a one line change in the various
nd6_*_output() routines and setting IPV6_TCLASS in rtadvd/rtsold.
Should it be sysctl'able or hard coded to a particular value? What
default? I'd lean towards 0xe0 at the moment, as it's compatible with
IP Precedence usage and IIRC I think I've seen packet traces where it
was used as well.

Unless the standards say "do it this way" and we comply, anything like
this should be optional/sysctlable.

[Patrik Lahti]

Post by der Mouse

In fact, network control should probably be the highest priority.

Oddly enough, it is, in the original ToS spec - page 12 of RFC 791. :)

And page 53 of RFC 1812 and RFC 2474 section 4.2.2. :-)

Although, as Greg pointed out, it would probably be Internetwork Control
- Precedence value 6.

I think it comes down to interpreting whether Internet Control includes
Neighbor Discovery or not.

Cheers!
/P

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Wed, 07 Jul 2010 09:10:51 -0400
From: Patrik Lahti <***@qnx.com>
Message-ID: <***@qnx.com>

| Although, as Greg pointed out, it would probably be Internetwork Control

No, if there's anything it isn't, it is that - internetwork control
is for stuff like BGP, packets needed to keep one network communicating
with others.

Network control is for routing within one network (organisation/ISP)
for typical IGP routing protocols or similar.

Whether ND is ever network control is debatable, but one thing it certainly
is not is internetwork control (or not in the sense of those terms as they
applied to the precedence bits).

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Patrik Lahti]

Post by Greg Troxel

Post by Patrik Lahti
I'm of the opinion that IPv6 Neighbor Discovery packets are network
control packets and hence they should be prioritized accordingly. In
fact, network control should probably be the highest priority.

At most they are internetwork control (old tos 6); network control is
about the layer used by the internetworking layer.

Yes, I think you're right.

Post by Greg Troxel

Post by Patrik Lahti
Currently Neighbor Discovery traffic is sent using the default (Best
Effort, i.e. zero) DSCP value, and e.g. if other higher traffic (lets
say a lot of voice traffic) is competing for bandwidth then it may
cease to function correctly potentially leading to all sorts of havoc.

What do the standards say? What do other operating systems do?

AFAICT the standards are open to interpretation as to what is
internetwork control.

I think I've seen routers set DSCP 0xe0 on ND packets, but not hosts.

/P


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Patrik Lahti]

Post by Patrik Lahti

Post by Greg Troxel
What do the standards say?

AFAICT the standards are open to interpretation as to what is
internetwork control.

PS. I haven't seen anything in the RFCs saying explicitly what DSCP any
ND message should use.

/P

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mihai Chelaru]

Post by Patrik Lahti

Post by Patrik Lahti

Post by Greg Troxel
What do the standards say?

AFAICT the standards are open to interpretation as to what is
internetwork control.

PS. I haven't seen anything in the RFCs saying explicitly what DSCP any
ND message should use.

What are others do ?