IP ToS/DSCP

[Patrik Lahti]

On 10-07-06 04:47 PM, sthaug at nethelp.no wrote:
>> The first reason for changing is that IPTOS_LOWDELAY is deprecated, and
>> DSCPs should really be used. Using a command line option lets the user
>> decide.
>
> This makes sense. But...
>
>> I'm coming at this from a different angle - reliability, not low delay.
>> DHCP can be considered to be network control type traffic. I.e. without
>> it functioning, there will be no IP connectivity. Consider a situation
>> where DHCP is renewing and due to excess packet loss (maybe because of a
>> lot of other traffic is saturating the link at higher priority, above
>> Best Effort) the renew messages are lost. Therefore DHCP enters
>> discovery again and the IP address is removed from the interface...
>
> If you regard DHCP traffic as important (network control type traffic)
> I assume you'd want the traffic from the clients to the server to be
> appropriately DSCP marked also. But in that case either the clients
> would have to do it themselves (is this at all realistic?), or you'd
> need to mark at the appropriate edge device (probably the DHCP relay
> agent). But if you can perform DSCP marking for the client traffic
> at the edge device, why can't you do similar marking at the switch/
> router closest to the server, for server to client traffic?
>
> I guess I'm saying that I'm not convinced about the need to do this
> in dhcpd at all. But if it is to be done in dhcpd then an option
> which accepted the appropriate DSCP value as an argument would be
> better, IMHO.
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no


The DSCP marking is not only important when packets pass through 
routers. Many network stacks include QoS mechanisms locally/internally 
based on DSCP, so setting DSCP in DHCP helps if congestion is 
experienced in the sender's network stack. Similarly, IP DSCP is 
commonly mapped to link layer QoS mechanisms (on Ethernet it's the p 
bits in the VLAN tag, wifi may use WMM) applied before the driver/HW 
outputs the frame on the link, so the it would help there as well.

Yes, I too think that the DSCP marking would be applied to both the 
traffic the client and server sends - the code I referred to, packet.c, 
is in the common code shared between them.

Sure, most deployments involve mix of DHCP implementations. But at least 
the ISC implementation would be doing the right thing and giving its 
users the command line option if they need it. And since it's a pretty 
popular implementation, others may follow.

Cheers!
/P