Re: Fw: issues with SO_PRIORITY and IP_TOS

Re: Fw: issues with SO_PRIORITY and IP_TOS

[kuznet]

Hello!

[cced to Jamal]

> I've always been confused about all of the weird things
> we do to handle DSCP et al. when masking the TOS bits all
> over the place.

TOS bits are masked only in one place: when doing routing by TOS,
implemented by some existing routing engines sort of OSPF. No bits
but TOS bits are used for these things.


> Alexey, what is going on here?

#1. Setting priority derived from TOS is different thing, it is
just to make life more convenient for old and still existing
applications: telnet, ftp, ssh, which set TOS bits in some way, which
used to be reasonable. Actually, even not four bits but only two bits
are used.

#2. If the host is inside diffserv environment all these things just
have no effects and make no sense. That's why we do not change anything
(except for disabling access to ECN bits).


> reasons.  Firstly, if we're using the old bit fields it should be the 
> precedence bits that are used for the skb priority rather than the tos 
> field. Secondly, the whole precedence/tos thing has been obsoleted by 
> the 6-bit DSCP field, of which the first 3 bits are supposed to be 
> backwards compatible with the old precedence field.  Shouldn't we 
> properly handle that?

See above #1. Precedence bits used to be _non-sense_ in the past and their use
outside of context of setup of your routers (in pre-DS world) or outide
context of diffserv does not make sense.

What's about "backward-compatibility", it sounds funny, DS is made compatible
with Cisco use precedence and this has nothing to do with end users
(where socket options make sense), precedence bits are rewritten by routers
for their own use.


> Secondly, for vlan priority tagging there are only 3 bits available. 
> This means that practically speaking anyone using vlan priorities needs 
> to limit themselves to priorities 0-7.

Thirdly. :-)

Technically speaking, direct access of user to such things is prohibited
in any case. So, use proper classifiers to do right mappings.


> Currently, for me to send a packet with IP precedence bits set to a 
> nonzero value *and* vlan priority set to the same value, I have to do 
> the following:
> 
> int opt = PRIORITY << 5;
> setsockopt(mysocks[i], SOL_IP, IP_TOS, &opt, sizeof(opt));
> opt = PRIORITY;
> setsockopt(mysocks[i], SOL_SOCKET, SO_PRIORITY, &opt, sizeof(opt));

This is right.


> This is kind of ugly.

Hmm.. This is kinda nice. IP_TOS sets real TOS bits without any funny
shifts and masks, but with some reasonable access control, SO_PRIORITY
sets priority. TOS and PRIORITY are not related.


>	  I propose adding a new IP socket option, IP_DSCP, 
> which would let you set the 6-bit DSCP value (which is then shifted by 
> two bits in the kernel to generate the 8-bit value for the header 
> field).  

I do not even think that IP_DSCP makes sense in diffserv environment.
Packets are marked according to DS rules, not according to desire
of particular user.

Anyway, the thing which you suggest is equal to IP_TOS in this part.


>	The high-order 3 bits would then be automatically used to set 
> the socket priority to make a vlan egress mapping simple.

Not even subject to discuss... In old current world it is just wrong,
in new world it is even wronger.

If DSCP is used for prioritizing, it is used via proper classifiers,
not via some rules hardcoded to kernel.

Alexey

Re: Fw: issues with SO_PRIORITY and IP_TOS

[Jamal Hadi Salim]

Hi,
I agree with Alexey in regards to DSCP should be done by classifiers.
Current mode of operation is: Whatever DSCP value you set will be reset
by the network/box manager depending on some criteria they set.  
Applications running as root or sudo can of course open a netlink
connection and set these values via a classifier.

Actually one important thing easy to miss is that the IEEE priorities
are reverse to what the IETF priorities are (who would have thunk, eh?).
I havent looked at the VLAN code however blindly using the
sk/skb->priority is _bad_ given that sk/skb->priority is based on IETF
semantics. I bet you the Linux vlan code doesnt know this.

cheers,
jamal

Re: Fw: issues with SO_PRIORITY and IP_TOS

[Chris Friesen]

kuznet@ms2.inr.ac.ru wrote:


>>Currently, for me to send a packet with IP precedence bits set to a 
>>nonzero value *and* vlan priority set to the same value, I have to do 
>>the following:
>>
>>int opt = PRIORITY << 5;
>>setsockopt(mysocks[i], SOL_IP, IP_TOS, &opt, sizeof(opt));
>>opt = PRIORITY;
>>setsockopt(mysocks[i], SOL_SOCKET, SO_PRIORITY, &opt, sizeof(opt));

> Hmm.. This is kinda nice. IP_TOS sets real TOS bits without any funny
> shifts and masks, but with some reasonable access control, SO_PRIORITY
> sets priority. TOS and PRIORITY are not related.

If that were the case, I'd be happy.  However, when you set the TOS bits 
(which really sets the whole 8-bit field, rather than just the 4 TOS 
bits), the kernel also sets the socket priority but only uses the TOS 
bits to do so.  If we're going to set the whole 8-bit field, wouldn't it 
make sense to use the priority bits to set the priority?  Or even leave 
the socket priority totally alone?

This is why I proposed the IP_DSCP option which would have sane handling 
of the socket priority when setting the DSCP value.

> I do not even think that IP_DSCP makes sense in diffserv environment.
> Packets are marked according to DS rules, not according to desire
> of particular user.

If root wants to send out a packet with particular DSCP settings, 
doesn't it make sense to make that option available?  It's a field in 
the IP packet header, we should be able to set it with an IP option.


Chris



-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: Fw: issues with SO_PRIORITY and IP_TOS

[Jamal Hadi Salim]

On Tue, 2003-11-04 at 12:02, Chris Friesen wrote:

> > I do not even think that IP_DSCP makes sense in diffserv environment.
> > Packets are marked according to DS rules, not according to desire
> > of particular user.
> 
> If root wants to send out a packet with particular DSCP settings, 
> doesn't it make sense to make that option available?  It's a field in 
> the IP packet header, we should be able to set it with an IP option.
> 

Just to give you some history:
This topic has been discussed to death in the past. Look at the diffserv
mailing lists.
Common practise is that the network manager controls the DSCP. They
_never_ trust the user. Of course this gives a lot of power to
network managers and router vendors such as nortel. But these guys
own the network. Qos is a way for them to make more money from different
services. The only OS vendor that made noise on this was MS. And they
lost too. I think thye now have a diffserv API which is not different
from what we have on tc.

BTW, i would worry about the vlan 802.1p QoS settings. While they may
appear to give you QoS within the box, once those bits start crossing
the network with switches that do 802.1q/p you may find that the result
is the opposite. 

cheers,
jamal

Re: Fw: issues with SO_PRIORITY and IP_TOS

[kuznet]

Hello!

> If that were the case, I'd be happy.  However, when you set the TOS bits 
> (which really sets the whole 8-bit field, rather than just the 4 TOS 
> bits),

It was not our choice. :-)


> the kernel also sets the socket priority but only uses the TOS 
> bits to do so. 

Look at straces of your telnet, ftp and ssh. You will understand why
it is made and why it would be better not to change this. It affects
local queuing in right way in default situation.


>      If we're going to set the whole 8-bit field, wouldn't it 
> make sense to use the priority bits to set the priority?

There are no "priority" bits in this field. Priority is defined
by outgoing device.


> If root wants to send out a packet with particular DSCP settings, 
> doesn't it make sense to make that option available?  It's a field in 
> the IP packet header, we should be able to set it with an IP option.

IP_TOS. :-)

I feel there is some misunderstanding about sk->priority thing.
It is the lowest significance hint about priority, when no other
classification is supplied. Read: when the node is dumb and is not aware
about any such things.

I would agree with you if this field had opposite priority:
i.e. overrided all the system-wide settings. It does not.

What's about VLAN thing, this approach enforces you to use
DSCP directly and never use skb->priority (well, to be more exact,
to use it when you have no another hints available: in this case
our skb->priority is _right_ hint)

Alexey

Re: Fw: issues with SO_PRIORITY and IP_TOS

[Chris Friesen]

kuznet@ms2.inr.ac.ru wrote:

> What's about VLAN thing, this approach enforces you to use
> DSCP directly and never use skb->priority (well, to be more exact,
> to use it when you have no another hints available: in this case
> our skb->priority is _right_ hint)

Okay, maybe you can help me out then.

I would like to send a vlan tagged packet, with vlan priority of x and 
DSCP field of (x<<5).  What is the proper way to do this, if I should 
not be using skb->priority?

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: Fw: issues with SO_PRIORITY and IP_TOS

[kuznet]

Hello!

> I would like to send a vlan tagged packet, with vlan priority of x and 
> DSCP field of (x<<5).  What is the proper way to do this, if I should 
> not be using skb->priority?

To set DSCP field you set the thing known as TOS with IP_TOS.

To set VLAN priority, you tune VLAN f.e. to use DSCP bits in classifier
to derive VLAN priority from those bits of DSCP, which you desire. DSCP>>5
in your case.


And remember that if the box is DS aware, DS will rewrite your DSCP
in the way consistent with sustem configuration.

Alexey

Re: Fw: issues with SO_PRIORITY and IP_TOS

[Chris Friesen]

kuznet@ms2.inr.ac.ru wrote:

> To set VLAN priority, you tune VLAN f.e. to use DSCP bits in classifier
> to derive VLAN priority from those bits of DSCP, which you desire. DSCP>>5
> in your case.

Excellent.  How do I do this?  I know of the egress mapping of socket 
priority to vlan priority.  How do I map DSCP to vlan priority?

I know how to do this by setting the socket priority with another 
setsockopt call, but is there a way of doing this directly?

Chris



-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com