[Planetlab-devel] Re: CAP_NET_ADMIN for setting ToS in IPv4 header
(was Re: [CVS] svn.planet-lab.org - check in: r16735 -
caglar at CS.Princeton.EDU
Fri Jan 22 14:56:12 EST 2010
On Jan 22, 2010, at 11:13 AM, Marc Fiuczynski wrote:
> Hi Caglar,
> On Jan 22, 2010, at 10:47 AM, caglar at CS.Princeton.EDU wrote:
>> vsys script for letting users to set the Type of Services(ToS) byte in the IPv4 header
>> + gcc fd_tos.c fdpass.o -o exec/fd_tos
> Thank you for putting together this solution using vsys. Vsys is a nice solution for punching a fine grain hole into Linux's coarse grain capabilities.
> However, in this particular case I think Linux just gets this wrong. According to the manual pages for the SO_PRIORITY socket option: Set the protocol-defined priority for all packets to be sent on this socket. Linux uses this value to order the networking queues: packets with a higher priority may be processed first depending on the selected device queueing discipline. For ip(7), this also sets the IP type-of-service (TOS) field for outgoing packets. Setting a priority outside the range 0 to 6 requires the CAP_NET_ADMIN capability.
OK, It turns out that vsys script is not needed for setting the TOS bit for values defined in the netinet/ip.h (but it's needed for higher values). These predefined TOS values automatically sets the SO_PRIORITY option without requiring a CAP_NET_ADMIN capability.
IP_TOS is 0
IP_TOS set 8
IP_TOS is 8
SO_PRIORITY is 2
SO_PRIORITY set 3
SO_PRIORITY is 3
> For implementing per stream outbound bandwidth limits on the node I think it sufficient to just use the ToS range of 0..6. My only concern then is the statement "Linux uses this value to order the networking queues: packets with a higher priority may be processed first depending on the selected device queueing discipline", which is a horribly vague statement. For what we are doing, I'd be fine with some sort of IP tables rule that clears the ToS field for ranges 0..6.
S.Çağlar Onur <caglar at cs.princeton.edu>
More information about the Devel