Windows Core Networking : ndis

WiFi WMM Requirements for Vista Miniport Drivers

wndpteam — Tue, 18 Sep 2007 18:00:31 GMT

A number of partners who author wireless drivers for Vista have asked how they can ensure their WiFi Wireless Multimedia (WMM) implementation is correct, so I thought I'd be explicit about this very important topic. To begin, read the 4-part series WiFi QoS Support in Windows Vista, which describes how Vista internally indicates a WMM Access Category (WMM_AC), how to detect whether an Access Point supports this capability, and how to observe the behavior of prioritized traffic. Next, be sure you explicitly validate your driver does the following:

Confirm the QoS header exists in 802.11 data frames when DSCP and 802.1p are set independently:

DSCP [56, 48, 40, 32, 24, 16, 8, 0]
802.1p [7, 6, 5, 4, 3, 2, 1, 0]

Ensure the miniport indicates NDIS_MAC_OPTION_8021P_PRIORITY in OID_GEN_MAC_OPTIONS
Miniport behavior on receive:

If WMM/11e header is stripped, WMM bit in FrameControlSubtype must be cleared
If WMM/11e header is not stripped, WMM bit in FrameControlSubtype must *not* be cleared
Must *not* strip 802.1Q tag in SNAP header (nwifi.sys will strip if necessary

Miniport behavior on transmit:

Only use NDIS_NET_BUFFER_LIST_8021Q_INFO.WMMInfo field to ascertain correct WMM_AC (*not* UserPriority, or IP DSCP field)
Must not strip 802.1Q tag in SNAP header (may be added by nwifi.sys)

-- Gabe Frost

Detecting 802.1p Priority Tags: Part 3

wndpteam — Sat, 15 Sep 2007 01:39:23 GMT

Parts 1 and 2 of this series discussed how to determine whether an 802.1p tag was added to traffic, and how to modify the NDIS light-weight-filter (LWF) sample driver source code to accomplish this task. We do know that you're all very busy and not everyone is a developer, so we've added to the package: full source code for the complete filter driver, a command-line tool for accessing the filtered packets, and compiled binaries for you non-developers. We also added the ability to validate *both* 802.1p and DSCP (from the IPv4/IPv6 header). This additional package was added to the existing download, so if you haven't already read part-2 of this series, do so now and you'll find download instructions there. For installation instructions, read the README file in the zip archive.

What do you think? Is this approach (source and tools) helpful? We do actively monitor the QoS forum, so let us know how we can improve your understanding of Windows QoS capabilities.

-- Gabe Frost

-- Huge thanks to Hemant Banavar who authored the tools

Detecting 802.1p Priority Tags: Part 2

wndpteam — Fri, 14 Sep 2007 02:43:33 GMT

In Gabe’s last post on detecting 802.1p priority tags, he described at a relatively high-level why it is difficult to detect a priority tag using packet tracing applications, as well as the proper way to determine whether a tag was present in a packet that was sent onto the wire (or air). In this post, I’ll describe how to programmatically access this information by modifying the NDIS Light Weight Filter (LWF) sample driver found in the Windows Driver Kit (WDK). To begin, download and install the WDK and navigate to the LWF sample found in the WinDDK\6000\src\network\ndis\filter directory. The remainder of this post will describe how to modify this sample to gain access to the UserPriority value in the out-of-band (OOB) data of a Net Buffer List (NBL) structure, and whether the miniport driver actually stripped the 1Q tag from the Ethernet header like it was supposed to. Based on what part-1 of this series describes about driver (miniport/LWF) layering and framing details, the modified driver will inspect received packets (meaning the sender added the tag to outgoing traffic).

The source file in the LWF sample of particular interest is filter.c, where we’ll modify the FilterReceiveNetBufferLists() function. FilterReceiveNetBufferLists() is an optional function for filter drivers, which if provided, processes receive indications made by the underlying miniport or filter drivers beneath in the stack. If this handler is NULL, NDIS will skip calling this filter when processing a receive indication and will call the next filter (or protocol driver) above in the stack with a non-NULL FilterReceiveNetBufferLists handler. The remainder of this post goes into detail about which areas of filter.c need to be modified.

To begin, let’s explore how to access the received packets in this function so they can be inspected. The second parameter to the function, NetBufferLists, is a linked list of NetBufferList structures allocated by the underlying driver. Each NetBufferList contains one NetBuffer structure, which represents a received packet. This means, in order to inspect each packet in the NetBufferLists linked list, we need a loop of the following kind within FilterReceiveNetBufferLists():

if (pFilter->TrackReceives)
{
     FILTER_ACQUIRE_LOCK(&pFilter->Lock, DispatchLevel);
     pFilter->OutstandingRcvs += NumberOfNetBufferLists;
     Ref = pFilter->OutstandingRcvs;
     currNbl = NetBufferLists;
     while(currNbl)
     {
          // Call the function to parse the packet in each
          // NetBufferList (one net buffer per NBL )
          inspectNetBuffer(currNbl, pFilter);
          currNbl = currNbl->Next;
     }
     FILTER_LOG_RCV_REF(1, pFilter, NetBufferLists, Ref);
     FILTER_RELEASE_LOCK(&pFilter->Lock, DispatchLevel);
}

In the above code snippet, observe that the loop is run only if pFilter->TrackReceives is TRUE. The idea here is to only inspect packets if the user requests the driver to do receive-side inspections (our focus is on a debugging tool). The TrackReceives flag can be set to FALSE at FilterAttach and can be set to TRUE through an IOCTL. Look at the FilterDeviceIoControl() function in device.c for defining IOCTLs.

Now that we have a pointer to the NetBufferList structure which holds the packet information, let’s explore how to inspect the packet for the 802.1p tag (note you could also inspect the IPv4 or IPv6 header for DSCP here if you really wanted). The inspectNetBuffer function in the above code snippet starts by extracting the NetBuffer pointer from the NetBufferList. Please see the bottom of this post for instructions on where to download the full implementation of this function. Next, if an 802.1p tag is available in the OOB data, it is extracted and stored in the variable called UserPriority as follows:

if (NET_BUFFER_LIST_INFO
(pNetBufferList, Ieee8021QNetBufferListInfo) != 0)
{
Ndis8021QInfo.Value = NET_BUFFER_LIST_INFO(pNetBufferList, Ieee8021QNetBufferListInfo);
UserPriority = (UCHAR)Ndis8021QInfo.TagHeader.UserPriority;
}

At this point, a pointer to the start of the packet is obtained and stored in packetBuffer. The Ethernet header is parsed and RecdUnStrippedPackets (which is initialized to zero at the beginning before starting to track received packets) is incremented if it is found that the Ethernet header still contains the 802.1p tag - indicating the underlying miniport did not strip the tag as per NDIS documentation.

To download the full implementation of inspectNetBuffer(), as used to do the majority of parsing work, go to Microsoft Connect website and login using your passport account (create one if you don’t already have one). Once you have logged in, choose Available Connections on the left-hand side of the page, and select Windows Networking from the available connections (bottom half of the page). On the left-hand side of the Windows Networking page, choose Downloads, and select NDIS LWF Sample With Packet Priority Detection.

-- Hemant Banavar

The Case of Vista Multimedia Playback and Network Throughput

wndpteam — Mon, 27 Aug 2007 20:07:03 GMT

Mark Russinovich has a great post today on the what and how of the network/multimedia vista issue that people have recently been talking about. Amusingly enough a couple people on /. more or less figured it out, but are only modded 3 and lower. Go Figure.

-- Ari

WiFi QoS Support in Windows Vista: WMM part 2

wndpteam — Fri, 30 Jun 2006 11:00:00 GMT

My previous post on WiFi QoS (WMM) discussed the four access classes (BG, BE, VI, and VO) available for traffic differentiation. I also highlighted that packets containing either a layer-2 802.1p tag or layer-3 DSCP mark (i.e. packets associated with a QoS flow) will be added to the correct WMM access class by a Native WiFi (NWF) driver that supports WMM based on the WMMInfo field in the NDIS_NET_BUFFER_LIST_8021Q_INFO structure. However, I did not mention which 802.1p or DSCP values correspond to the four WMM access classes and therefore cause WMMInfo to be populated by Pacer.sys correctly. Before I can answer this, I need to provide a little more, you guessed it, background.

As Mathias described in his post about 802.1p, there are eight values (0-7) representing traffic classes from background to network control. Mathias also highlighted in his post about DSCP that there are 64 possible values for this field in the IP header. You may be thinking, that things don't align here, and you're right. Because WMM only has four possible traffic classes, and it relies on 802.1p and DSCP to indicate what traffic class to use, there needs to be some major consolidation. The following table lists the four WMM traffic classes and which 802.1p and DSCP values correspond:

802.1p	DSCP	WMM_AC
1	16	BG
2	8	BG
0	0	BE
3	24	BE
4	32	VI
5	40	VI
6	48	VO
7	56	VO

The Qos2 API removes the need to choose the correct 802.1p and/or DSCP values and instead provides a simple enum for available traffic classes:

typedef enum _QOS_TRAFFIC_TYPE {
QOSTrafficTypeBestEFfort,
QOSTrafficTypeBackground,
QOSTrafficTypeExcellentEffort,
QOSTrafficTypeAudioVideo,
QOSTrafficTypeVoice,
QOSTrafficTypeControl
} QOS_TRAFFIC_TYPE, *PQOS_TRAFFIC_TYPE;

The four traffic types that correspond to WMM_ACs are shown in red. By way of example, if a Qos2 application specified QOSTrafficTypeAudioVideo for QOS_TRAFFIC_TYPE, outgoing packets for this QoS flow would be marked with a DSCP value of 40 and may have an 802.1p tag with value 5. If you're wondering why I used the word "may" for an 802.1p tag, read my post on the necessity for end-to-end QoS experiments.

Let me know what you think.

- Gabe Frost

WiFi QoS Support in Windows Vista: WMM

wndpteam — Thu, 29 Jun 2006 05:22:00 GMT

In Windows Vista, a great deal of effort has gone into making it simple for network applications to take advantage of QoS capable networks. This post focuses on QoS for WiFi networks (both consumer and enterprise) and how the Vista network stack enables differentiated treatment of outgoing traffic. The WiFi Alliance has created a certification for Wireless Multimedia, or WMM, which identifies four access classes (WMM_AC from lowest to highest priority): background, best-effort, video, and voice. In abbreviated form, these classes are BG, BE, VI, and VO. If both the wireless station NIC and access point (AP) support WMM, it is possible to gain differentiated treatment for traffic sent. The good news is that many retail and enterprise APs support this feature, either out of the box, or in the most recent firmware available from the vendor. As for the wireless station adapter, the NIC driver must be WMM capable.

The WMM specification clearly states that traffic must be assigned to these four aforementioned WMM_AC (to receive differentiated treatment) based on either the MSDU 802.1Q UserPriority tag or the DSCP mark in the IP header of a packet. Importantly, from a Windows implementation perspective, the task of assigning outgoing traffic to the appropriate access class is carried out by the wireless NIC driver on the sending station. As such, this driver must be WMM capable. Like wireless APs, the good news is many 802.11g and 802.11a/b/g (and pre-n MIMO) wireless NICs support this feature, either out of the box, or in the most recent firmware available from the vendor.

Now that you have some background, the purpose of this post is to provide details on how (1) vendors writing Native WiFi (NWF) NIC drivers ascertain which access class to assign outgoing traffic to (create WMM capable drivers), and (2) how network sockets-based applications can gain differentiated treatment for traffic sent over the network.

1. In Windows Vista, the net buffer list (NBL) available to NDIS-6 drivers exposes a new field, WMMInfo, in the NDIS_NET_BUFFER_LIST_8021Q_INFO structure. A NWF driver need only examine the WMMInfo field to ascertain the correct WMM_AC. When sockets-based applications call QoS APIs or an enterprise QoS policy is enabled (see section 2 below), a QoS flow is created and maintained by the network packet scheduler (Pacer.sys). If 802.1Q UserPriority and/or DSCP are applied to this flow, Pacer.sys will automatically populate WMMInfo correctly. This means that the NIC driver does not have to incur a per-packet performance hit (an improvement over WinXP) from manually parsing each packet to determine the proper WMM_AC.

2. Windows Vista provides a simple set of APIs for adding QoS to sockets-based applications. These functions can be found in qos2.h. I’ll post a detailed description about Qos2 APIs shortly. Policy-Based QoS is also available, which enables IT administrators to specify Group Policies that indicate which applications/users/groups/etc should receive differentiated treatment from QoS capable routers and WiFi APs. Policy-based QoS can be used to easily enable and manage QoS on enterprise WiFi networks.

I am interested to hear any feedback or questions about the improved support for WMM in Windows Vista.

- Gabe Frost

The NDIS 6.0 Driver Model

wndpteam — Mon, 15 May 2006 21:00:00 GMT

NDIS 6.0 was introduced to the independent hardware vendor (IHV) and developer community at last year’s WinHEC. It brings the promise of greater performance, improved manageability, reduced complexity for NDIS miniports, and simpler models for writing intermediate and filter drivers. Are you curious how much of the promise has been realized?

At WinHEC this year, I’ll demonstrate network adapters which maximize network throughput with lower CPU utilization—all by moving to the NDIS 6.0 model. NDIS 6.0 miniport drivers have demonstrated 20% performance improvements over NDIS 5.1 miniport drivers!

Here are some examples of the feedback we’ve heard from some of our partners inside Microsoft, citing how NDIS 6.0 has made a difference in their scenarios.

Example 1: Pacer, the packet scheduling and shaping component of the Policy-based Quality of Service feature

The old Windows Packet Scheduler (PSched) was originally an NDIS 5.0 intermediate miniport. The new Windows Packet Scheduler (Pacer) uses the NDIS 6.0 lightweight filter model, resulting in better performance with lower overhead. In previous releases, enabling PSched in passive mode resulted in a 10% increase in CPU utilization. On Windows Vista, by contrast, enabling Pacer in passive mode results in an increase of only 0.5% in CPU utilization.

Example 2: Network Load Balancing (NLB)

The NLB development team told us that porting NLB from the intermediate miniport model to the lightweight filter model resulted in simpler code that was much easier to debug.

Example 3: Media Streaming and Interrupt Moderation

As the Quality of Service development team can attest, the OIDs for enabling and disabling interrupt moderation make a big difference in accurately measuring available bandwidth, which is key for smoother media streaming in home networks.

Want to see the improvements for yourself? Drop by the WinHEC Hardware showcase at the NDIS 6.0 booth to learn more about what the NDIS 6.0 model has to offer. Have questions for us on how the model works? Leave us a comment in response to this posting.

Aarti Bharathan

Program Manager, Core Networking

An Interview with Alireza Dabagh, NDIS development lead

wndpteam — Tue, 18 Apr 2006 04:37:00 GMT

Tell us about what you do in Windows.

I’m NDIS development lead. I lead a team which works on NDIS and related components, and I also contribute to the architecture, coding and design of our components.

How long have you been participating in WinHEC?

Quite some time! Maybe 4 or 5 years.

What are the challenges and opportunities you see ahead for core networking and the connectivity technologies that you work on?

One of the biggest challenges that we have is supporting multigigabit networking. As the raw bandwidth increases, the role of the entire stack becomes an obstacle to taking advantage of that bandwidth. It wasn’t an issue at 10/100Mbps, but it used to be an issue at 1Gbps. Today it’s not an issue anymore for 1Gbps but its an issue for 10Gbps. The challenge is to make sure we can take advantage of all the capacity that the network has to offer.

The other challenge is manageability and diagnosability. In today’s environment, many of the people who rely on networking are new to networking and they need a way to understand what’s going on, why connectivity is lost,or why performance isn’t what they expect, in a way that they can act on rather than through some cryptic error message. They need clearer explanations of these problems. For example, if you lose Internet connectivity at home, it’s hard to tell if it’s because your cable is disconnected, or if your cable or DSL modem is hung, or because your router needs to be reset, or because your provider isn’t giving you an address. It’s really hard for a regular user to diagnose these problems.

The third thing I’d mention is scalability. By that I mean being able to use multiple links, with features link load-balancing and fail-over. Today we have multiple solutions from various vendors, which behave in different ways and are often hard to use and managed. We’ve heard a lot of requests for supporting these features natively as part of the platform to provide a consistent experience.

How does virtualization affect the area that you work on?

I should have mentioned that as one of the challenges! When you only have one real interface in the system, but you want each guest OS to see its own virtual interface, you run into various issues. For example, how do you get the real NIC to receive packets for all the virtual interfaces? Today each NIC has one unicast MAC address. If you want to get frames for all those virtual MAC addresses, today you have to put the hardware into promiscuous mode which has its own implications. Dispatching those incoming packets to multiple virtual machines has its own performance and security implications. Having resources like DMA engines, I/OAT engines and being able to use it in multiple virtual machines is also challenging particularly with security. It’s challenging to take advantage of offloads like TCP chimney offload and task offload in virtual machines without any conflicts. Remember that you can only have one driver running the hardware, and that driver is ignorant of there being multiple virtual interfaces running over it. So you need a layer that manages virtualization requirements on top of the driver.

Any messages for the WinHEC audience?

Be sure to follow the progress of our NDIS APIs closely, particularly what we’re doing with IPsec offload, TCP chimney offload and task offload. We don’t want anyone to be left behind, so the WinHEC attendees should make sure they can take advantage of that. It’s no longer enough to just provide plain vanilla hardware, because competitors can provide these cool new capabilities with minimal expense. Networking hardware that doesn’t offer these capabilities will be at a great disadvantage. Getting this functionality isn’t the difference between $10 and $100 hardware for OEMs; it’s the difference between $10 and $12 hardware. So my advice is: don’t be left behind!

-Abolade Gbadegesin