Introduce QoS support in Wifi

This is my attempt to introduce QoS support in wifi. This code review obsoletes code review 294280043.

The changes can also be viewed on github:

https://github.com/stavallo/ns-3-dev-git/commits/qos-wifi

Here is a list of changes:

- a tos field has been added to InetSockAddress. This work is basically the one presented in code review 294280043, with some changes suggested by Tom and some other added to support tcp sockets too

- a SocketPriority tag has been introduced to carry the priority of a packet (what Linux stores in skb->priority). The priority of a socket can be set directly with a method of the Socket class. In case of IPv4, setting the TOS also sets the priority (see the Socket::IpTos2Priority method, which reproduces what is done by Linux). A SocketPriority tag is attached to the packet by UDP and TCP sockets in case the priority is not null. Since the priority must be used by netdevices, too, the SocketPriority tag is removed by the remote endpoint of the socket. Like Linux, if the packet is forwarded, the SocketPriority tag is updated based on the TOS field of the packet (in case of IPv4).

- The Socket::IsManualIpTos method is removed as it can be replaced by the Socket::GetIpTos method: a SocketIpTos tag is only added if the tos is not null. Given the changes above, I believe that allowing Ipv4L3Protocol to set a default TOS value makes no sense anymore and hence I removed the DefaultTos attribute

- before enqueuing a packet into a queue disc, the Traffic Control layer has to determine the netdevice queue in which the packet will be enqueued. To this purpose, multi-queue devices can register a select queue callback. One of the commits makes a little change here, i.e., the callback is stored by the traffic control layer itself so that the tc layer can directly invoke the callback (as opposed to the current situation where the callback is stored by the netdevice queue interface, hence the tc layer calls a netdevice queue interface method which invokes the callback). This change also allows the possibility to handle the future case of multi-queue devices that do not set a select queue callback, in which case the tc layer has to select a queue by means of a hash function.

- the function used by the Linux wireless stack to select the netdevice queue (i.e., the access category) makes use of the DS field (ToS for IPv4, Traffic class for IPv6). To this end, a GetUint8Value method is added to the QueueItem class, which allows to get the correct content of the DS field, if any, thanks to the specialization of QueueDiscItem in Ipv4QueueDiscItem and Ipv6QueueDiscItem

- finally, the WifiNetDevice::SelectQueue is added, which returns the Access Category based on the DS field of the packet (again, as Linux does). This function modifies the priority of the packet. Such priority turns out to be the user priority defined in 802.11 and hence the SocketPriority tag can replace the QosTag (there is also a commit which completely removes the QosTag). Some new methods could be avoided if RegularWifiMac::GetQosSupported was public instead of protected.

[Stefano Avallone, 2016-07-01 13:45:56]

Just to let you know that I added another commit to the series (published on my
qos-wifi github branch) to make PfifoFastQueueDisc classify packets based on
their priority (guess why? Linux does so). This is rather important to have a
correct (i.e., adhering to Linux) behavior in case of wifi, where the priority
is modified by the select queue function  before the packet is enqueued into the
queue disc. Hence, pfifo_fast in Linux maps packets to bands based on the
priority set by the 802.11 select queue function, instead of the priority
returned by the rt_tos2priority function.

[S. Deronne, 2016-07-02 09:27:54]

Is it planned to be delivered in the mainstream in the coming days?
I would like to deliver txop changes (https://codereview.appspot.com/293190043)
this week. Otherwise example would have to be delivered a bit later.

[Stefano Avallone, 2016-07-02 11:02:33]

On 2016/07/02 09:27:54, S. Deronne wrote:
> Is it planned to be delivered in the mainstream in the coming days?

I cannot answer, as it is up to you all to voice objections :-) Anyway, my
opinion is that this patch is basically ready, as the two tests show that it is
working correctly. The things to look at more carefully are:

- the introduction of the tos field to the InetSockAddress class (Tom already
said he liked the idea)
- the introduction of the priority attribute and the priority tag
- the introduction of the GetUint8Value method to the QueueItem class

Please also note that the patch series includes some commits that are not
strictly necessary, (i.e., things work correctly even without them but I believe
it is good to apply them), hence we might also postpone pushing them:

- removal of Socket::IsManualIpTos ()
- removal of Ipv4L3Protocol::DefaultTos attribute
- moving the select queue callback from NetDeviceQueueInterface to
TrafficControl
- removal of the QosTag

[Tom Henderson, 2016-07-02 15:49:05]

I will review the rest of the code as soon as possible, but I have an initial
question, based on my reading of the summary text.

> Since the priority must be used by netdevices, too, the 
> SocketPriority tag is removed by the remote endpoint of the 
> socket.

I don't see why the SocketPriority tag is not removed before the packet hits the
channel, rather than at the remote endpoint; shouldn't a 'socket' tag be scoped
to the local host?

[Stefano Avallone, 2016-07-02 17:12:16]

On 2016/07/02 15:49:05, Tom Henderson wrote:
> I will review the rest of the code as soon as possible, but I have an initial
> question, based on my reading of the summary text.
> 
> > Since the priority must be used by netdevices, too, the 
> > SocketPriority tag is removed by the remote endpoint of the 
> > socket.
> 
> I don't see why the SocketPriority tag is not removed before the packet hits
the
> channel, rather than at the remote endpoint; shouldn't a 'socket' tag be
scoped
> to the local host?

Yes, it should be scoped to the local host, but I was not able to identify a
proper place to remove the socket tag. Any idea? Please keep in mind that the
use of the socket tag is not limited to wifi.

[Tom Henderson, 2016-07-06 04:55:37]

On 2016/07/02 17:12:16, Stefano Avallone wrote:
> On 2016/07/02 15:49:05, Tom Henderson wrote:
> > I will review the rest of the code as soon as possible, but I have an
initial
> > question, based on my reading of the summary text.
> > 
> > > Since the priority must be used by netdevices, too, the 
> > > SocketPriority tag is removed by the remote endpoint of the 
> > > socket.
> > 
> > I don't see why the SocketPriority tag is not removed before the packet hits
> the
> > channel, rather than at the remote endpoint; shouldn't a 'socket' tag be
> scoped
> > to the local host?
> 
> Yes, it should be scoped to the local host, but I was not able to identify a
> proper place to remove the socket tag. Any idea? Please keep in mind that the
> use of the socket tag is not limited to wifi.

maybe MacLow?  I agree to remove it where you later remove it on inbound socket
but it seems possibly cleaner to also remove it in WiFi when you are done with
it (and perhaps add this removal to our other devices).

[Tom Henderson, 2016-07-06 04:58:56]

I didn't really spot any points for discussion (only one comment).

To finish off, I suggest some user guidance documentation somewhere about how
users may configure their applications to set the Tos, and how this influences
how priority is set lower in the stack.

it may be confusing that there are both IpTos and Priority tags and how they
interact is not documented; the udp-test code shows by example how they
interact, but perhaps documentation would help too.

https://codereview.appspot.com/302880043/diff/1/src/internet/model/ipv4-l3-pr...
File src/internet/model/ipv4-l3-protocol.cc (right):

https://codereview.appspot.com/302880043/diff/1/src/internet/model/ipv4-l3-pr...
src/internet/model/ipv4-l3-protocol.cc:1046: if (packet->RemovePacketTag
(priorityTag) || ipHeader.GetTos ())
I wasn't sure about this check; should a priority tag be set below if
ipHeader.GetTos () is zero?

[S. Deronne, 2016-07-06 20:22:11]

Looks ok, I do not have comments, just as mentioned Tom documentation should be
extended.

[Stefano Avallone, 2016-07-07 17:00:33]

Thanks for reviewing this work. Here is a second version, which differs from the
previous one in that:

- the patch to make PfifoFastQueueDisc classify packets based on their priority
(previously published on github) has been included in the code review

- packet sockets now support adding a priority tag if the socket has a priority
set. Note that packets sent through packet sockets are passed directly to the
netdevices, thus bypassing the traffic control layer. This implies that
WifiNetDevice::SelectQueue is not called

- documentation has been added to various places

-Ipv4L3Protocol::IpForward removes the priority tag (if any) and adds a new
priority tag if the priority corresponding to the ToS field is not null.
Ipv6L3Protocol::IpForward also removes the priority tag, if any.

- MacLow::StartTransmission removes the priority tag, if any. I hope it suffices
to guarantee that all the packets sent through wifi are priority tag free. I
chose this method because it seems to me it is the only useful point where a
packet copy is performed (WifiMacQueues store a Ptr<const Packet> which does not
allow to remove tags)

- the traffic control layer (if no queue disc is installed) and the queue discs
remove the priority tag from the packets just before sending the packets to the
netdevice, in case the netdevice has a single queue. The rationale is that a
netdevice that stores all the packets in a single queue makes no use of the
priority of a packet. This required to modify a bit the udp-test, in order to
catch packets while in the queue disc instead of while in the netdevice queue.
This should ensure that all the packets sent on the channel are priority tag
free (the only multi-queue device is wifi which removes the priority tags). If
you disagree with this approach, we can remove it.

A final observation. We introduced a public GetTxQueuesN method both in WifiMac
and RegularWifiMac in order to know whether the mac supports QoS or not. An
alternative approach to get rid of such GetTxQueuesN methods would be to make
RegularWifiMac::GetQosSupported public instead of protected (the QosSupported
attribute already allows to access -- and even modify -- the m_qosSupported
member) and add such GetQosSupported method to WifiMac as well. Which approach
do you prefer?

[S. Deronne, 2016-07-07 17:52:05]

On 2016/07/07 17:00:33, Stefano Avallone wrote:
> Thanks for reviewing this work. Here is a second version, which differs from
the
> previous one in that:
> 
> - the patch to make PfifoFastQueueDisc classify packets based on their
priority
> (previously published on github) has been included in the code review
> 
> - packet sockets now support adding a priority tag if the socket has a
priority
> set. Note that packets sent through packet sockets are passed directly to the
> netdevices, thus bypassing the traffic control layer. This implies that
> WifiNetDevice::SelectQueue is not called
> 
> - documentation has been added to various places
> 
> -Ipv4L3Protocol::IpForward removes the priority tag (if any) and adds a new
> priority tag if the priority corresponding to the ToS field is not null.
> Ipv6L3Protocol::IpForward also removes the priority tag, if any.
> 
> - MacLow::StartTransmission removes the priority tag, if any. I hope it
suffices
> to guarantee that all the packets sent through wifi are priority tag free. I
> chose this method because it seems to me it is the only useful point where a
> packet copy is performed (WifiMacQueues store a Ptr<const Packet> which does
not
> allow to remove tags)
> 
> - the traffic control layer (if no queue disc is installed) and the queue
discs
> remove the priority tag from the packets just before sending the packets to
the
> netdevice, in case the netdevice has a single queue. The rationale is that a
> netdevice that stores all the packets in a single queue makes no use of the
> priority of a packet. This required to modify a bit the udp-test, in order to
> catch packets while in the queue disc instead of while in the netdevice queue.
> This should ensure that all the packets sent on the channel are priority tag
> free (the only multi-queue device is wifi which removes the priority tags). If
> you disagree with this approach, we can remove it.
> 
> A final observation. We introduced a public GetTxQueuesN method both in
WifiMac
> and RegularWifiMac in order to know whether the mac supports QoS or not. An
> alternative approach to get rid of such GetTxQueuesN methods would be to make
> RegularWifiMac::GetQosSupported public instead of protected (the QosSupported
> attribute already allows to access -- and even modify -- the m_qosSupported
> member) and add such GetQosSupported method to WifiMac as well. Which approach
> do you prefer?

I see no problem to make it public.

[S. Deronne, 2016-07-07 17:52:29]

https://codereview.appspot.com/302880043/diff/20001/src/wifi/model/mac-low.cc
File src/wifi/model/mac-low.cc (right):

https://codereview.appspot.com/302880043/diff/20001/src/wifi/model/mac-low.cc...
src/wifi/model/mac-low.cc:747: m_currentPacket->RemovePacketTag (priorityTag);
Did you check tag is also removed in case aggregation is used?

[Tom Henderson, 2016-07-07 17:53:35]

> 
> A final observation. We introduced a public GetTxQueuesN method both in
WifiMac
> and RegularWifiMac in order to know whether the mac supports QoS or not. An
> alternative approach to get rid of such GetTxQueuesN methods would be to make
> RegularWifiMac::GetQosSupported public instead of protected (the QosSupported
> attribute already allows to access -- and even modify -- the m_qosSupported
> member) and add such GetQosSupported method to WifiMac as well. Which approach
> do you prefer?

On this point specifically, I think that Get/SetQosSupported could be deleted
from RegularWifiMac since as you point out, users can directly access this
boolean from the attribute system.  i.e.

    .AddAttribute ("QosSupported",
                   "This Boolean attribute is set to enable 802.11e/WMM-style
QoS support at this STA.",
                   BooleanValue (false),
-                   MakeBooleanAccessor (&RegularWifiMac::SetQosSupported,
-                                        &RegularWifiMac::GetQosSupported),
+                  MakeBooleanAccessor (&RegularWifiMac::m_qosSupported),
                   MakeBooleanChecker ())

because Set/GetQosSupported() are not public, are not virtual, and do not do
anything but touch this underlying variable.

However, whether or not we decide to delete these, in your code, where you need
to do this:

+              m_queueInterface->SetTxQueuesN (m_mac->GetTxQueuesN ());

you can access the QosSupported attribute using the usual Object::GetAttribute()
method.

2) We probably should have named NetDeviceQueueInterface::GetTxQueuesN ()
instead to either GetNTxQueues or GetNumTxQueues, which would be more in line
with the rest of the ns-3 API that queries for sizes (where the "N" is not
postfixed anywhere else, AFAIK).  We could consider to replace and deprecate
GetTxQueuesN method name...

[Tom Henderson, 2016-07-07 17:58:19]

> 
> - packet sockets now support adding a priority tag if the socket has a
priority
> set. Note that packets sent through packet sockets are passed directly to the
> netdevices, thus bypassing the traffic control layer. This implies that
> WifiNetDevice::SelectQueue is not called
> 

Is there still a way to test WiFi QoS (e.g. EDCA behavior) using packet sockets?
 The reason this is useful is to write unit tests on EDCA that do not require
internet or traffic control layers.

[Stefano Avallone, 2016-07-07 18:07:36]

On 2016/07/07 17:58:19, Tom Henderson wrote:
> Is there still a way to test WiFi QoS (e.g. EDCA behavior) using packet
sockets?
>  The reason this is useful is to write unit tests on EDCA that do not require
> internet or traffic control layers.

Yes, you have to set the priority (using Socket::SetPriority) to the user
priority expected by wifi. You cannot set UP 7 because SetPriority allows to set
the priority in the range 0..6. I did not test it myself, but I am willing to
help in case of troubles.

[Stefano Avallone, 2016-07-07 18:18:27]

On 2016/07/07 17:53:35, Tom Henderson wrote:
> On this point specifically, I think that Get/SetQosSupported could be deleted
> from RegularWifiMac since as you point out, users can directly access this
> boolean from the attribute system.  i.e.
> 
>     .AddAttribute ("QosSupported",
>                    "This Boolean attribute is set to enable 802.11e/WMM-style
> QoS support at this STA.",
>                    BooleanValue (false),
> -                   MakeBooleanAccessor (&RegularWifiMac::SetQosSupported,
> -                                        &RegularWifiMac::GetQosSupported),
> +                  MakeBooleanAccessor (&RegularWifiMac::m_qosSupported),
>                    MakeBooleanChecker ())
> 
> because Set/GetQosSupported() are not public, are not virtual, and do not do
> anything but touch this underlying variable.
> 
> However, whether or not we decide to delete these, in your code, where you
need
> to do this:
> 
> +              m_queueInterface->SetTxQueuesN (m_mac->GetTxQueuesN ());
> 
> you can access the QosSupported attribute using the usual
Object::GetAttribute()
> method.

I noticed that attribute while writing the message and did not realize I could
use it instead of introducing the GetTxQueuesN method. Will do the change you
suggested later. I'll leave it up to you to decide whether to remove
Set/GetQosSupported () or not.
 
> 2) We probably should have named NetDeviceQueueInterface::GetTxQueuesN ()
> instead to either GetNTxQueues or GetNumTxQueues, which would be more in line
> with the rest of the ns-3 API that queries for sizes (where the "N" is not
> postfixed anywhere else, AFAIK).  We could consider to replace and deprecate
> GetTxQueuesN method name...

Agree, I will commit this fix tomorrow.

[Stefano Avallone, 2016-07-07 18:24:08]

On 2016/07/07 17:52:29, S. Deronne wrote:
> Did you check tag is also removed in case aggregation is used?

I did not test that. I understood that MacLow::StartTransmission sends both MSDU
and A-MSDU, so the tag should be removed also in case aggregation is used. But I
may be wrong, my knowledge of the wifi code is not complete. I will investigate
this case tomorrow.

[S. Deronne, 2016-07-07 18:45:38]

On 2016/07/07 18:24:08, Stefano Avallone wrote:
> On 2016/07/07 17:52:29, S. Deronne wrote:
> > Did you check tag is also removed in case aggregation is used?
> 
> I did not test that. I understood that MacLow::StartTransmission sends both
MSDU
> and A-MSDU, so the tag should be removed also in case aggregation is used. But
I
> may be wrong, my knowledge of the wifi code is not complete. I will
investigate
> this case tomorrow.

In case of A-MPDU it is not true, please check aggregateToAmpdu function.

[Stefano Avallone, 2016-07-08 12:11:58]

On 2016/07/07 18:45:38, S. Deronne wrote:
> On 2016/07/07 18:24:08, Stefano Avallone wrote:
> > On 2016/07/07 17:52:29, S. Deronne wrote:
> > > Did you check tag is also removed in case aggregation is used?
> > 
> > I did not test that. I understood that MacLow::StartTransmission sends both
> MSDU
> > and A-MSDU, so the tag should be removed also in case aggregation is used.
But
> I
> > may be wrong, my knowledge of the wifi code is not complete. I will
> investigate
> > this case tomorrow.
> 
> In case of A-MPDU it is not true, please check aggregateToAmpdu function.

Packets are stored in the queue for MPDU aggregation (m_aggregateQueue) by the
aggregateToAmpdu function only, which is only called by IsAmpdu, which is only
called by StartTransmission after the priority tag has been removed. Hence, it
seems to me that the tag is removed before MPDUs can be aggregated. Do you
agree?

[Stefano Avallone, 2016-07-08 14:28:08]

Another version to address latest comments:

- removed [Regular]WifiMac::GetTxQueuesN by using the QosSupported attribute

- modified PacketSocketClient as suggested by Tom

- renamed NetDeviceQueueInterface::GetTxQueuesN to GetNTxQueues

[S. Deronne, 2016-07-12 17:33:24]

Thanks I'll check the PacketSocketClient.
If no other comments pop up, could it be delivered since I have some
dependencies for txop?

[Tom Henderson, 2016-07-12 19:10:07]

On 2016/07/12 17:33:24, S. Deronne wrote:
> Thanks I'll check the PacketSocketClient.
> If no other comments pop up, could it be delivered since I have some
> dependencies for txop?

I agree to try to hasten the delivery of this to ns-3-dev since others depend on
it.

My only remaining comment is on IPv6.  I realize that our sockets do not support
IPV6_TCLASS.  However, being able to set priorities from applications seems to
be a useful feature to have for both v4 and v6.  

In v4, the way to do it is to either add the Tos value in the InetSocketAddress
(passed to Bind or Connect) or to manually SetIpTos() on existing socket if one
has a pointer to that socket.  However, users may not set the priority tag
directly on the socket; it is scrubbed at the Ipv4L3Protocol layer regardless of
whether TOS is set.  Probably the most useful mechanism is the InetSocketAddress
technique since user-level code typically handles these and it is generic to all
(non-QoS-aware) applications.

In v6, there doesn't seem to be a way to do this.  Is the plan to extend
InetSocketAddress and IPv6 sockets according to IPV6_TCLASS?  Or should we
consider to allow users to access a socket directly at the application level and
set the priority tag directly?

If the latter, we could consider to remove this part of the patch:
https://codereview.appspot.com/302880043/patch/40001/50011

also could consider to remove the part in Ipv4 that scrubs it, since it might be
counter-intuitive for a user who directly sets a SocketPriority tag on an Ipv4
socket to have it scrubbed and have no effect in the tc/device layers.

[Stefano Avallone, 2016-07-12 21:47:38]

On 2016/07/12 19:10:07, Tom Henderson wrote:
> My only remaining comment is on IPv6.  I realize that our sockets do not
support
> IPV6_TCLASS.  However, being able to set priorities from applications seems to
> be a useful feature to have for both v4 and v6.  
> 
> In v4, the way to do it is to either add the Tos value in the
InetSocketAddress
> (passed to Bind or Connect) or to manually SetIpTos() on existing socket if
one
> has a pointer to that socket.  However, users may not set the priority tag
> directly on the socket; it is scrubbed at the Ipv4L3Protocol layer regardless
of
> whether TOS is set.

Actually, a priority tag carrying the socket priority is attached to packets by
the Socket::Send()/SendTo() methods. The socket priority is set by both
SetPriority() and SetIpTos(). Thus, if SetPriority() is called after SetIpTos()
(e.g., after Bind() or Connect()), the priority tag will carry the priority set
by SetPriority(). The priority tag is not scrubbed by the Ipv4L3Protocol layer,
the code you are likely referring to is in the IpForward() method and thus only
applies to forwarded packets. Such code adds a priority tag to forwarded packets
based on the value of the ToS field (like Linux does).

> Probably the most useful mechanism is the InetSocketAddress
> technique since user-level code typically handles these and it is generic to
all
> (non-QoS-aware) applications.
> 
> In v6, there doesn't seem to be a way to do this.  Is the plan to extend
> InetSocketAddress and IPv6 sockets according to IPV6_TCLASS?  Or should we
> consider to allow users to access a socket directly at the application level
and
> set the priority tag directly?

Well, the only way to set the priority for IPv6 (except in the case of wifi,
where the user priority is set by the select queue function based on the IPv6
traffic class) is to call SetPriority(), if one has a pointer to the socket. The
same approach as IPv4 cannot be used here because Linux does not set the socket
priority as a consequence of setting the traffic class. Thus, the latter would
be the only option in my opinion.

> If the latter, we could consider to remove this part of the patch:
> https://codereview.appspot.com/302880043/patch/40001/50011

This part of the patch should ensure that the scope of a priority tag is local
to a node. In case of IPv6, no priority is assigned to forwarded packets
(because the priority is not derived from the traffic class).

> also could consider to remove the part in Ipv4 that scrubs it, since it might
be
> counter-intuitive for a user who directly sets a SocketPriority tag on an Ipv4
> socket to have it scrubbed and have no effect in the tc/device layers.

I mentioned earlier that this only applies to forwarded packets and is done to
enforce the locality of the priority. Setting the priority does have effects in
the tc/device layers, as shown by the new pfifo_fast test.

[Tom Henderson, 2016-07-12 23:08:26]

On 2016/07/12 21:47:38, Stefano Avallone wrote:
> On 2016/07/12 19:10:07, Tom Henderson wrote:
> > My only remaining comment is on IPv6.  I realize that our sockets do not
> support
> > IPV6_TCLASS.  However, being able to set priorities from applications seems
to
> > be a useful feature to have for both v4 and v6.  
> > 
> > In v4, the way to do it is to either add the Tos value in the
> InetSocketAddress
> > (passed to Bind or Connect) or to manually SetIpTos() on existing socket if
> one
> > has a pointer to that socket.  However, users may not set the priority tag
> > directly on the socket; it is scrubbed at the Ipv4L3Protocol layer
regardless
> of
> > whether TOS is set.
> 
> Actually, a priority tag carrying the socket priority is attached to packets
by
> the Socket::Send()/SendTo() methods. The socket priority is set by both
> SetPriority() and SetIpTos(). Thus, if SetPriority() is called after
SetIpTos()
> (e.g., after Bind() or Connect()), the priority tag will carry the priority
set
> by SetPriority(). The priority tag is not scrubbed by the Ipv4L3Protocol
layer,
> the code you are likely referring to is in the IpForward() method and thus
only
> applies to forwarded packets. Such code adds a priority tag to forwarded
packets
> based on the value of the ToS field (like Linux does).

Yes, my mistake for not reading enough context around that part of the patch (I
thought it was in the LOCAL_OUT direction).

> 
> 
> Well, the only way to set the priority for IPv6 (except in the case of wifi,
> where the user priority is set by the select queue function based on the IPv6
> traffic class) is to call SetPriority(), if one has a pointer to the socket.
The
> same approach as IPv4 cannot be used here because Linux does not set the
socket
> priority as a consequence of setting the traffic class. Thus, the latter would
> be the only option in my opinion.

OK

> 
> > If the latter, we could consider to remove this part of the patch:
> > https://codereview.appspot.com/302880043/patch/40001/50011
> 
> This part of the patch should ensure that the scope of a priority tag is local
> to a node. In case of IPv6, no priority is assigned to forwarded packets
> (because the priority is not derived from the traffic class).

Yes, disregard my suggestion to delete.

[Stefano Avallone, 2016-07-13 13:07:11]

On 2016/07/12 23:08:26, Tom Henderson wrote:
> > Well, the only way to set the priority for IPv6 (except in the case of wifi,
> > where the user priority is set by the select queue function based on the
IPv6
> > traffic class) is to call SetPriority(), if one has a pointer to the socket.
> The
> > same approach as IPv4 cannot be used here because Linux does not set the
> socket
> > priority as a consequence of setting the traffic class. Thus, the latter
would
> > be the only option in my opinion.
> 
> OK

Anyway, I would postpone adding additional means for setting the priority for
IPv6 packets, because I think some discussions are needed. Please let me know if
I need to make other changes or I can commit this patch series.

[Tom Henderson, 2016-07-13 17:21:36]

On 2016/07/13 13:07:11, Stefano Avallone wrote:
> On 2016/07/12 23:08:26, Tom Henderson wrote:
> > > Well, the only way to set the priority for IPv6 (except in the case of
wifi,
> > > where the user priority is set by the select queue function based on the
> IPv6
> > > traffic class) is to call SetPriority(), if one has a pointer to the
socket.
> > The
> > > same approach as IPv4 cannot be used here because Linux does not set the
> > socket
> > > priority as a consequence of setting the traffic class. Thus, the latter
> would
> > > be the only option in my opinion.
> > 
> > OK
> 
> Anyway, I would postpone adding additional means for setting the priority for
> IPv6 packets, because I think some discussions are needed. Please let me know
if
> I need to make other changes or I can commit this patch series.

I think we have enough consensus to push now.

[Stefano Avallone, 2016-07-14 15:41:37]

On 2016/07/13 17:21:36, Tom Henderson wrote:
> I think we have enough consensus to push now.

Pushed. Thanks for reviewing this patch series!