IP ToS/DSCP

[sthaug at nethelp.no]

> 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