Alineo

hi,
I made an application who overwrite dscp value with TC API and it runs ok.
Now I try to set/mark the 802.1p for layer 2 with the same api .
I took the same code and change the QOS_DS_CLASS by QOS_TRAFFIC_CLASS
my question is how modify the generic filter for change the pattern for taking the layer 2 (vlan) and not the layer 3 ( IP)

thank you for your help...


Re: Network Quality of Service (QoS/qWAVE) 802.1p marking packet with Winsock2

Gabe Frost

I need to ask a clarifying question, and think you should get some background. For starters, yes, TC is the only API by which you can set arbitrary layer-2 priority tag (802.1p). GQoS does not allow setting layer-2 priority (only layer-3 DSCP) and qWAVE (qos2) will only set layer-2 for adaptive flows (QOSAddSocketToFlow is *not* called with the QOS_NON_ADAPTIVE_FLOW flag) where the end-to-end path between source and destination will not drop a packet that contains the 802.1p tag. Essentially, qWAVE does an experiment to determine whether the tag will get dropped, and won't add it if so. You take a risk using TC to add layer-2 tag because it does not do this test and the frame may get dropped by some intermediate network element (network switch or NIC on receiving station).

All that said, I'm not sure what you mean by modifying a TC filter (which is used to match traffic for applying flow properties to) You set 802.1p essentially the same way you set DSCP. In the flow setup, you specify that you want layer-2, layer-3, or both priorities, and what specific value to use. A filter has nothing to do with it. I may be missing something, so please elaborate on what you are trying to do, and I'll try to be of more help. Are you asking specifically how to set 802.1p tag instead of DSCP in the flow creation

-- Gabe Frost [MSFT]





Re: Network Quality of Service (QoS/qWAVE) 802.1p marking packet with Winsock2

Alineo

Hi Gabe
First, I am conscious of the risks with TC and I try to set 802.1p bit on outgoing packets for a specific port.
I used QOS Traffic control API for DSCP and it was successful.
I follow to same way that DSCP but it don't work.
I looked on the net but many people have the same problem and there are not answer.
To finish I enable 802.1p on my NIC
Thank's




Re: Network Quality of Service (QoS/qWAVE) 802.1p marking packet with Winsock2

Gabe Frost

How are you comming to the conclusion that 802.1p tags aren't being added to outgoing traffic For starters, Windows NDIS documentation specifically requires NDIS miniport drivers to strip the 802.1p tag on the receive path, and populate the out-of-band structure with the information for drivers further up the stack. Also, because it's actually the miniport/NIC that adds the 802.1p tag to outgoing frames on the transmit path, tracing software such as NetMon or WireShark will not see the tag. In review:

  • Tracing software won't see the tag on Tx or Rx path for well behaving NICs. On Tx, the tracing software sits above the driver which actually adds the tag. On Rx, the miniport (if behaving) will strip the tag before sending up the stack (where the tracing software lives)

The only way you can detect if a tag is in a frame is if you purposly use a NIC which behaves incorrectly on the receiving machine, i.e. does not strip the 1p tag on receive. You would then run the sniffer software on that receiving machine to detect the tag. Alternatively, you can write an NDIS filter driver that inspects the out-of-band data structure to see if 1Q.UserPriority is populated.

-- Gabe Frost [MSFT]





Re: Network Quality of Service (QoS/qWAVE) 802.1p marking packet with Winsock2

Alineo

Thank you for your answer.
But i put the sniffer on my pc which receive the socket and where the 802.1p NIC option was disabled, and I saw anything...
In the other side, I didn't know how do a filte for the NDIS...
I hope you can help me, please.
Have a good day.
Thank you




Re: Network Quality of Service (QoS/qWAVE) 802.1p marking packet with Winsock2

Gabe Frost

This is the correct behavior. It does not matter if the 802.1p tagging option is enabled in the NIC on the receive side. NDIS specification explicitly says any packet received that has an 802.1p tag; the tag must be removed before passing up the stack (the 802.1p tag option only applies to packets being sent, not received). This is why you cannot see the 802.1p tag by running a sniffer on the sender or the receiver. The only way to actually see the tag is to find a NIC which does not follow NDIS specification (some REALTEK NICs operate this way), or to write an NDIS intermediate (NDIS IM) driver which examines the following structure:

NDIS_NET_BUFFER_LIST_8021Q_INFO.UserPriority

The latter is the best option. Please look in the Windows SDK for the NDIS IM sample driver as a starting point. You can then modify this code to look at the above mentioned structure. When the miniport driver removes the 802.1p tag, it populates NDIS_NET_BUFFER_LIST_8021Q_INFO.UserPriority with the value.