Windows Core Networking : QoS

QoS Traffic Generator Example Usage

AriPernick — Fri, 08 May 2009 02:47:52 GMT

In my last post, I announced the availability of QoS Traffic Generator on Microsoft Connect. In order to help you understand the usage of this tool, I have provided some examples of what it can do.

One of the most common tasks is to send traffic from one computer to another. The following example sends UDP traffic at 5 Mbps for 10 seconds.

Source

C:\qos>qostraffic.exe -source -udp -dest 192.168.1.100 -throttle 5000000 
                      -duration 10
Parsing command line...
WSAStartup successful.
Time between each packet (microsec): 2400
Size of each packet: 1472
Statistics sampling interval (msec): 1000
Sending traffic at 5.00 Mbps to 192.168.1.100:9999
Date, Time, Packets received, Bytes received (headers included), Elapsed time (msec), Throughput (Kbps), Bottleneck BW, Available BW, RTT, BBSet, ABSet, RTTSet, ErrorCode
05/07/2009, 23:06:54, 421, 631500, 1014, 4982.249,,,,,,,
05/07/2009, 23:06:55, 422, 633000, 1014, 4994.083,,,,,,,
05/07/2009, 23:06:56, 423, 634500, 1014, 5005.917,,,,,,,
05/07/2009, 23:06:57, 422, 633000, 1014, 4994.083,,,,,,,
05/07/2009, 23:06:58, 423, 634500, 1014, 5005.917,,,,,,,
05/07/2009, 23:06:59, 422, 633000, 1014, 4994.083,,,,,,,
05/07/2009, 23:07:00, 423, 634500, 1014, 5005.917,,,,,,,
05/07/2009, 23:07:01, 422, 633000, 1014, 4994.083,,,,,,,
05/07/2009, 23:07:02, 423, 634500, 1014, 5005.917,,,,,,,
Time has elapsed, or CTRL+C has been pressed.
Stopping Source traffic, waiting 5 sec.
SenderThread is exiting...
SenderThread exited successfully.
WSACleanup successful.

Sink

C:\qos>qostraffic.exe -sink -udp
Parsing command line...
Listening on all IP addresses.
WSAStartup successful.
Waiting for UDP traffic on port 9999, hit CTRL+C to exit...
WSARecvFrom completed.
Date, Time, Packets received, Bytes received (headers included), Elapsed time (msec), Throughput (Kbps), Message
05/07/2009, 23:06:54, 421, 631500, 1014, 4982.249,
05/07/2009, 23:06:55, 422, 633000, 1014, 4994.083,
05/07/2009, 23:06:56, 423, 634500, 1014, 5005.917,
05/07/2009, 23:06:57, 422, 633000, 1014, 4994.083,
05/07/2009, 23:06:58, 423, 634500, 1014, 5005.917,
05/07/2009, 23:06:59, 422, 633000, 1014, 4994.083,
05/07/2009, 23:07:00, 423, 634500, 1014, 5005.917,
05/07/2009, 23:07:01, 422, 633000, 1014, 4994.083,
05/07/2009, 23:07:02, 423, 634500, 1014, 5005.917,

You can see the throughput in Kbps from the last column, along with other information such as timestamp and bytes received. The QoS Traffic Generator can also support multiple TCP connections from one sink. The next example shows two TCP flows, one using qWave and one using TC (used to throttle traffic) sending to the same destination.

Source 1

C:\qos>qostraffic.exe -source -tcp -dest 192.168.1.100 -throttle 1000000 -qwave
Parsing command line...
qWave traffic type: Best effort
qWave flow type: non-adaptive.
qWave LLTD option: system choice.
qWave flow fundamentals: do not display
WSAStartup successful.
qWave started up successfully.
Send interval: not used, packets will be sent as fast as possible
Packets to send per interval: 1
Size of each packet: 1000
Statistics sampling interval (msec): 1000
Sending traffic at 1.00 Mbps to 192.168.1.100:9999
Date, Time, Packets received, Bytes received, Elapsed time (msec), Throughput (Kbps), Bottleneck BW, Available BW, RTT, BBSet, ABSet, RTTSet, ErrorCode
05/07/2009, 23:02:04, 129, 125000, 1014, 986.193,,,,,,,
05/07/2009, 23:02:05, 126, 126000, 1014, 994.083,,,,,,,
05/07/2009, 23:02:06, 125, 125000, 1014, 986.193,,,,,,,
05/07/2009, 23:02:07, 126, 126000, 1014, 994.083,,,,,,,
05/07/2009, 23:02:08, 124, 124000, 1014, 978.304,,,,,,,
05/07/2009, 23:02:09, 127, 127000, 1015, 1000.985,,,,,,,
05/07/2009, 23:02:10, 125, 125000, 1014, 986.193,,,,,,,
05/07/2009, 23:02:11, 126, 126000, 1014, 994.083,,,,,,,
05/07/2009, 23:02:12, 125, 125000, 1014, 986.193,,,,,,,
05/07/2009, 23:02:14, 124, 124000, 1014, 978.304,,,,,,,
05/07/2009, 23:02:15, 126, 126000, 1014, 994.083,,,,,,,
05/07/2009, 23:02:16, 127, 127000, 1014, 1001.972,,,,,,,
05/07/2009, 23:02:17, 125, 125000, 1014, 986.193,,,,,,,
05/07/2009, 23:02:18, 124, 124000, 1014, 978.304,,,,,,,
ERROR: 64 in GetQueuedCompletionStatus: The specified network name is no longer 
available.
SenderThread is exiting...
SenderThread exited successfully.
Stopping Source traffic, waiting 5 sec.
SenderThread exited successfully.
WSACleanup successful.

Source 2

C:\qos>qostraffic.exe -source -tcp -dest 192.168.1.100 -throttle 2000000 -tc 40,4
Parsing command line...
WSAStartup successful.
Send interval: not used, packets will be sent as fast as possible
Packets to send per interval: 1
Size of each packet: 1000
Statistics sampling interval (msec): 1000
Sending traffic at 2.00 Mbps to 192.168.1.100:9999
Date, Time, Packets received, Bytes received, Elapsed time (msec), Throughput (Kbps), Bottleneck BW, Available BW, RTT, BBSet, ABSet, RTTSet, ErrorCode
05/07/2009, 23:01:59, 498, 498000, 1014, 3928.994,,,,,,,
05/07/2009, 23:02:00, 248, 248000, 1014, 1956.607,,,,,,,
05/07/2009, 23:02:01, 251, 251000, 1014, 1980.276,,,,,,,
05/07/2009, 23:02:02, 251, 251000, 1014, 1980.276,,,,,,,
05/07/2009, 23:02:03, 252, 252000, 1014, 1988.166,,,,,,,
05/07/2009, 23:02:04, 247, 247000, 1014, 1948.718,,,,,,,
05/07/2009, 23:02:05, 251, 251000, 1014, 1980.276,,,,,,,
05/07/2009, 23:02:07, 251, 251000, 1014, 1980.276,,,,,,,
05/07/2009, 23:02:08, 251, 251000, 1014, 1980.276,,,,,,,
05/07/2009, 23:02:09, 247, 247000, 1014, 1948.718,,,,,,,
05/07/2009, 23:02:10, 251, 251000, 1014, 1980.276,,,,,,,
05/07/2009, 23:02:11, 251, 251000, 1014, 1980.276,,,,,,,
05/07/2009, 23:02:12, 251, 251000, 1014, 1980.276,,,,,,,
05/07/2009, 23:02:13, 252, 252000, 1014, 1988.166,,,,,,,
05/07/2009, 23:02:14, 250, 250000, 1014, 1972.387,,,,,,,
05/07/2009, 23:02:15, 252, 252000, 1014, 1988.166,,,,,,,
05/07/2009, 23:02:16, 251, 251000, 1014, 1980.276,,,,,,,
05/07/2009, 23:02:17, 251, 251000, 1014, 1980.276,,,,,,,
05/07/2009, 23:02:18, 247, 247000, 1014, 1948.718,,,,,,,
ERROR: 64 in GetQueuedCompletionStatus: The specified network name is no longer 
available.
SenderThread is exiting...
SenderThread exited successfully.
Stopping Source traffic, waiting 5 sec.
SenderThread exited successfully.
WSACleanup successful.

Sink

C:\qos>qostraffic.exe -sink -tcp
Parsing command line...
Listening on all IP addresses.
WSAStartup successful.
Waiting for TCP traffic on port 9999, hit CTRL+C to exit...
AcceptEx has successfully completed.
Overlapped AcceptEx signaled.
Connection received: ::ffff:157.59.28.243:56677 --> ::ffff:192.168.1.100:9999
Date, Time, Packets received, Bytes received, Elapsed time (msec), Throughput (Kbps), Message
05/07/2009, 23:01:59, 498, 498000, 1014, 3928.994,
05/07/2009, 23:02:00, 248, 248000, 1014, 1956.607,
05/07/2009, 23:02:01, 251, 251000, 1014, 1980.276,
05/07/2009, 23:02:02, 251, 251000, 1014, 1980.276,
Overlapped AcceptEx signaled.
Connection received: ::ffff:157.59.28.243:56678 --> ::ffff:192.168.1.100:9999
Date, Time, Packets received, Bytes received, Elapsed time (msec), Throughput (Kbps), Message
AcceptEx has successfully completed.
05/07/2009, 23:02:03, 252, 252000, 1014, 1988.166,
05/07/2009, 23:02:04, 129, 125000, 1014, 986.193,
05/07/2009, 23:02:04, 247, 247000, 1014, 1948.718,
05/07/2009, 23:02:05, 126, 126000, 1014, 994.083,
05/07/2009, 23:02:05, 251, 251000, 1014, 1980.276,
05/07/2009, 23:02:06, 125, 125000, 1014, 986.193,
05/07/2009, 23:02:07, 251, 251000, 1014, 1980.276,
05/07/2009, 23:02:07, 126, 126000, 1014, 994.083,
05/07/2009, 23:02:08, 251, 251000, 1014, 1980.276,
05/07/2009, 23:02:08, 124, 124000, 1014, 978.304,
05/07/2009, 23:02:09, 247, 247000, 1014, 1948.718,
05/07/2009, 23:02:09, 127, 127000, 1015, 1000.985,
05/07/2009, 23:02:10, 251, 251000, 1014, 1980.276,
05/07/2009, 23:02:10, 125, 125000, 1014, 986.193,
05/07/2009, 23:02:11, 251, 251000, 1014, 1980.276,
05/07/2009, 23:02:11, 126, 126000, 1014, 994.083,
05/07/2009, 23:02:12, 251, 251000, 1014, 1980.276,
05/07/2009, 23:02:12, 125, 125000, 1014, 986.193,
05/07/2009, 23:02:13, 252, 252000, 1014, 1988.166,
05/07/2009, 23:02:14, 124, 124000, 1014, 978.304,
05/07/2009, 23:02:14, 250, 250000, 1014, 1972.387,
05/07/2009, 23:02:15, 126, 126000, 1014, 994.083,
05/07/2009, 23:02:15, 252, 252000, 1014, 1988.166,
05/07/2009, 23:02:16, 127, 127000, 1014, 1001.972,
05/07/2009, 23:02:16, 251, 251000, 1014, 1980.276,
05/07/2009, 23:02:17, 125, 125000, 1014, 986.193,
05/07/2009, 23:02:17, 251, 251000, 1014, 1980.276,
05/07/2009, 23:02:18, 124, 124000, 1014, 978.304,
05/07/2009, 23:02:18, 247, 247000, 1014, 1948.718,
Event set, thread exiting.
Receive thread exiting.
ReceiverThread exited successfully.
Control Event or Stop() called. TCP receive thread is exiting.
Main receive thread exited successfully.
WSACleanup successful.

The sink prints out statistics from both sources and was stopped using CTRL+C after about 20 seconds. Both traffic sources then exit gracefully. A full list of options is shown below.

C:\qos>qostraffic.exe -?
Parsing command line...
Need to specify -source or -sink flag.

QoS Traffic Generator (Daytona), v. 1.0

Usage:

Sink: qostraffic -sink -tcp/-udp/-tcp_a 
                 [-dest destIP,destPort -local localIP,localPort] ...
Source: qostraffic -source -tcp/-udp/-tcp_a -dest destIP,destPort 
                   -throttle rate
                   [-local localIP,localPort -duration sec] ...

Sink flags:
-tcp/-udp       Listens for TCP/UDP traffic
                default: listens on all addresses, port 9999
-tcp_a          Connects to source and then begins receiving traffic
                Source must also specify -tcp_a flag
                Note: start the source first, then the sink
-dest           OPTIONAL
                Destination address to connect to for -tcp_a
                Ignored for -tcp/-udp cases
-local          OPTIONAL
                Listens on specific local address/port
                default port: 9999
                Note: Can specify different port to listen on with,
                      localPort only.
-qwave          OPTIONAL
                Starts up qWave service.
                Used for adaptive flows from the source.
-noconsole      OPTIONAL
                Suppresses console output
                default is not suppressed
Source flags:
-tcp/-udp       Listens for TCP/UDP traffic
-tcp_a          Accepts connection from sink then sends traffic
                Sink must also specify -tcp_a flag
                Note: start the source first, then the sink
-dest           Send traffic to destination address/port
                default port: 9999
                Note: ignored for -tcp_a case
-throttle       Throttles traffic at specified rate (bits/sec)
-pull           OPTIONAL
                Operates the source in pull mode.
                Note: supported for TCP traffic only.
-local          OPTIONAL
                Send traffic from specified local address/port
                default port: 9999
                Note: for -tcp_a case, this is the local address to 
                      listen on
-duration       OPTIONAL
                Send traffic for specified time (sec)
                default: infinite
-stats          OPTIONAL
                Prints out statistics for specified time (msec)
                default: 1000 msec
                minimum: 200 msec
-qwave          OPTIONAL
                Uses qWave with the specified options (all optional)
                ,,
                trafficType: traffic type defined by QoS subsystem
                        BE - best effort (default)
                        BCK - background
                        EE - excellent effort
                        AV - audio/video
                        VO - voice
                        CTRL - control
                adaptive: force use adaptive flow
                        default is nonadaptive
                lltd: force use LLTD packets
                        default lets system choose LLTD or not
                flowfund: prints out QueryFlowFundamentals
                        prints bandwidth estimations every 25 ms
                        only supported when using adaptive flows
                EXAMPLE: -qwave AV,LLTD
-server         Optional, when used with qWave will prevent doing 
                   QOSStartTracking/QOSStopTracking
                Note: conflicts with -tc flag.
-tc             OPTIONAL
                Uses TC with the specified options (all optional)
                ,<1p>
                dscp: DSCP value ranging from 0 to 63
                        default lets system choose
                1p: 802.1p tag ranging from 0 to 7
                        default lets system choose
                Specifying -1 for either value is equivalent to 
                default. EXAMPLE: -tc 40,4
                Note: conflicts with -qwave flag. Must be run as 
                      admin.
-packet         OPTIONAL
                Performs packet experiments with given options (all 
                required)
                ,,
                size - size of each packet in bytes
                num - number of packets to send
                interval - time between each send in ms
                EXAMPLE: -packet 59,50,100
                This will send a 59 byte packet every 100 ms, 50 
                times total.
                Note: packets can be tagged by using -tc options.
-log            OPTIONAL
                Logs to the specified file
                default filename: is "daytona_.txt"
-noconsole      OPTIONAL
                Suppresses console output
                default is not suppressed
-localstats     OPTIONAL
                Prints statistics from source
                default is sink side stats
                Note: conflicts with packet option, results will be 
                undefined
-tolerance      OPTIONAL
                Specify tolerance
                If no tolerance will assume 2%

Hopefully this post has been helpful in understanding what the QoS Traffic Generator can do. Please send us any comments you have!

-- Jim Liu

QoS Traffic Generator is now available on Connect

AriPernick — Fri, 01 May 2009 02:35:05 GMT

I’m posting on behalf of Jim Liu who is a SDET in Windows Core Networking. -- Ari

The QoS team is pleased to announce the availability of the QoS Traffic Generator on Microsoft Connect. This tool was developed during the Windows 7 development process and has been used extensively to aid in the testing of our QoS technologies. It is a command-line based tool that generates network traffic and utilizes TC/qWave to throttle and mark packets as desired. Some notable features include:

· Ability to send traffic at a specified throughput using Winsock from one machine to another

· Throttling is performed by the application itself or through QoS APIs (Traffic Control or qWave)

· Support TCP and UDP dual-mode sockets

· Provide traffic statistics from either the source machine or destination machine

· Can be built as a static library for use in other applications

We are providing this tool as a demonstration of QoS technologies and how they may be used to produce a novel application. Both 32 and 64-bit binaries are provided along with the source code and instructions for building the static library and the accompanying executable. The application itself has usage information on the available usage options.

To download the package, go to the WNDP site on Microsoft Connect and select Downloads from the left-hand menu. Select QoS Traffic Generator. Please send us any feedback you have about the tool!

-- Jim Liu

QoS in Windows 7

charwen — Wed, 28 Jan 2009 03:40:00 GMT

Hello all. My name is Charley. I’m the new QoS program manager for Windows Core Networking.

It has been a while since we posted our last article about QoS. We want to assure you that we’re still committed to improving this technology and building new QoS features in Windows. We received many questions and suggestions from you in the past. We hope you continue doing so because they are important to us.

You probably all know that Windows 7 beta is live and available for you to download. You may wonder what is new in Windows 7 regarding QoS. But before getting to that, I’d like to refresh our memory as to what was new in Windows Vista. In Vista, we introduced two major QoS features: qWAVE and Policy based QoS. qWAVE, or Quality Windows Audio Video Experience, is designed to estimate the network bandwidth, intelligently mark the application packets (with proper DSCP values), and interact with the application in the event of network congestion or fluctuations of available bandwidth (so that the application can take appropriate actions). qWAVE APIs aim to simplify the work of application developers developing QoS-enabled applications for a home network. The APIs are documented in the Windows SDK. In contrast, Policy based QoS has a different target audience. It is intended to enable IT administrators to apply QoS to applications (which don’t need to have native supports of QoS), computers, and users in their enterprise network. It is especially beneficial to an organization with branch offices, where the WAN link capacity is limited and users tend to experience unpredictable network delays when accessing files or applications hosted on the main campus (or a different branch office). If you’d like to know more about these features, we’d suggest you read an excellent article written by Joseph Davies for TechNet magazine. Click here to check it out.

So what’s new in Windows 7? The enhancement we’ve made is called URL based QoS. If you’re familiar with Policy based QoS you know that in Vista an IT administrator can create a policy based on the application name, source and/or destination IP addresses, source and/or destination ports, and the protocol (TCP, UDP, or both). We’ve learned since then that many enterprise applications have been, or will be, hosted on web servers and accessed from a browser, so the IT administrators would love to be able to prioritize or control the network traffic from those web-based applications, provided that a convenient configuration is available. To answer their request, we’ve added a new configuration option: you can create a policy based on the URL of an HTTP server. Say, you host all the training videos of your company on an IIS server running Windows 7 (or more precisely, Windows Server 2008 R2). You can then use a URL based QoS policy to throttle the video traffic (to prevent it from overwhelming your corporate network). Or, you host your company’s CRM or ERP applications on an HTTP application server running Windows 7. You can similarly use a URL based QoS policy to prioritize these applications traffic so that even users at a remote branch office always get prompt replies and have smooth UI experience.

Does this sound interesting to you? Please let us know what you think. In the next blog, we’ll detail the configuration and the rules.

Charley

Throttling, DSCP, and 802.1p with Traffic Control

wndpteam — Thu, 15 Nov 2007 02:07:39 GMT

In his introductory post about the legacy Traffic Control (TC) API, Gabe discussed the host-based model that TC provides. In this post, we will see how Traffic Control APIs can be used to achieve the following for TCP/IPv4 and UDP/IPv4 traffic sent from a host:

Throttle (rate-limit) outgoing traffic
Add DSCP value in layer-3 (IPv4) header
Indicate that an 802.1p tag value should be added in layer-2 header

At the bottom of the post, we’ve provided a link to the Networking Connect site to download full source and binaries to a tool which implements all of the above functionality.

The following are the steps involved:

1. The first step in the process is to obtain a handle to the Traffic Control subsystem through a call to TcRegisterClient().

2. Next, make a call to TcEnumerateInterfaces() using the registration handle obtained in step #1. This call returns a list of all TC enabled interfaces on the system. Iterate through the list to find the interface(s) on which you want to prioritize and/or throttle outgoing traffic.

3. For each interface of interest, issue a TcOpenInterface() using the pInterfaceName from the corresponding TC_IFC_DESCRIPTOR for that interface from the list returned in step#2. Store the handle returned by TcOpenInterface(); let’s call it the ifchandle.

4. At this point, create a TC Flow and add it to the interface(s) of interest.

a. Create the TC Flow:
A TC flow is a way of describing various QoS characteristics to be applied to a set of packets and is represented by a TC_GEN_FLOW structure. The following code snippet shows how to create a TC Flow given the DSCP value, 802.1p value and the throttle rate.

BOOL CreateFlow(PTC_GEN_FLOW * _ppTcFlowObj, USHORT DSCPValue, USHORT OnePValue, ULONG ThrottleRate)
{
BOOL status = FALSE;
//
// Flow Parameters
//
ULONG TokenRate = QOS_NOT_SPECIFIED;
ULONG TokenBucketSize = QOS_NOT_SPECIFIED;
ULONG PeakBandwidth = QOS_NOT_SPECIFIED;
ULONG Latency = QOS_NOT_SPECIFIED;
ULONG DelayVariation = QOS_NOT_SPECIFIED;
SERVICETYPE ServiceType = SERVICETYPE_BESTEFFORT;
ULONG MaxSduSize=QOS_NOT_SPECIFIED;
ULONG MinimumPolicedSize=QOS_NOT_SPECIFIED;
PVOID pCurrentObject;
PTC_GEN_FLOW _pTcFlowObj = NULL;
int Length = 0;
//
// Calculate the memory size required for the optional TC objects
//
Length += (OnePValue == NOT_SPECIFIED ? 0:sizeof(QOS_TRAFFIC_CLASS)) + (DSCPValue == NOT_SPECIFIED ? 0:sizeof(QOS_DS_CLASS));
//
// Print the Flow parameters
//
printf("Flow Parameters:\n");
DSCPValue == NOT_SPECIFIED ? printf("\tDSCP: *\n"):printf("\tDSCP: %u\n", DSCPValue);
OnePValue == NOT_SPECIFIED ? printf("\t802.1p: *\n"):printf("\t802.1p: %u\n", OnePValue);
ThrottleRate == QOS_NOT_SPECIFIED ? printf("\tThrottleRate: *\n"):printf("\tThrottleRate: %u\n", ThrottleRate);
TokenRate = TokenBucketSize = ThrottleRate;
//
// Allocate the flow descriptor
//
_pTcFlowObj = (PTC_GEN_FLOW)malloc(FIELD_OFFSET(TC_GEN_FLOW, TcObjects) + Length);
if (!_pTcFlowObj)
{
    printf("Flow Allocation Failed\n");
    goto Exit;
}
_pTcFlowObj->SendingFlowspec.TokenRate = TokenRate;
_pTcFlowObj->SendingFlowspec.TokenBucketSize = TokenBucketSize;
_pTcFlowObj->SendingFlowspec.PeakBandwidth = PeakBandwidth;
_pTcFlowObj->SendingFlowspec.Latency = Latency;
_pTcFlowObj->SendingFlowspec.DelayVariation = DelayVariation;
_pTcFlowObj->SendingFlowspec.ServiceType = ServiceType;
_pTcFlowObj->SendingFlowspec.MaxSduSize = MaxSduSize;
_pTcFlowObj->SendingFlowspec.MinimumPolicedSize = MinimumPolicedSize;
//
// Currently TC only supports QoS on the send path
// ReceivingFlowSpec is legacy and ignored
//
memcpy(&(_pTcFlowObj->ReceivingFlowspec), &(_pTcFlowObj->SendingFlowspec), sizeof(_pTcFlowObj->ReceivingFlowspec));
_pTcFlowObj->TcObjectsLength = Length;
//
// Add any requested objects
//
pCurrentObject = (PVOID)_pTcFlowObj->TcObjects;
if(OnePValue != NOT_SPECIFIED)
{
    QOS_TRAFFIC_CLASS *pTClassObject = (QOS_TRAFFIC_CLASS*)pCurrentObject;
    pTClassObject->ObjectHdr.ObjectType = QOS_OBJECT_TRAFFIC_CLASS;
    pTClassObject->ObjectHdr.ObjectLength = sizeof(QOS_TRAFFIC_CLASS);
    pTClassObject->TrafficClass = OnePValue; //802.1p tag to be used
    pCurrentObject = (PVOID)(pTClassObject + 1);
}
if(DSCPValue != NOT_SPECIFIED)
{
    QOS_DS_CLASS *pDSClassObject = (QOS_DS_CLASS*)pCurrentObject;
    pDSClassObject->ObjectHdr.ObjectType = QOS_OBJECT_DS_CLASS;
    pDSClassObject->ObjectHdr.ObjectLength = sizeof(QOS_DS_CLASS);
    pDSClassObject->DSField = DSCPValue; //Services Type
}
DeleteFlow(_ppTcFlowObj);
*_ppTcFlowObj = _pTcFlowObj;
status = TRUE;
Exit:
if(!status)
{
    printf("Flow Creation Failed\n");
    DeleteFlow(&_pTcFlowObj);
}
else
    printf("Flow Creation Succeeded\n");
return status;
}

b. Add the Flow on the interface:
After obtaining a TC_GEN_FLOW structure with the desired characteristics using a function similar to the one above, issue a call to TcAddFlow() with the ifchandle (obtained in step #3) and a pointer to the TC_GEN_FLOW object (obtained in step #4a). Store the handle returned by TcAddFlow();let’s call it the flowhandle.

5. The next step is to create a TC Filter and add it to the TC Flow created above.

a. Create the TC Filter:
A TC Filter is a way of describing which packets to apply the QoS characteristics to. The QoS characteristics defined in the TC_GEN_FLOW will only apply to the packets matching the filter(s) associated with the Flow.
The following code snippet describes how to create a TC Filter given the destination address, the destination port, and the protocol (TCP,UDP or IP).

BOOL CreateFilter(PTC_GEN_FILTER * ppFilter, SOCKADDR_STORAGE Address, USHORT Port, UCHAR ProtocolId)
{

BOOL status = FALSE;
USHORT AddressFamily = Address.ss_family;
PTC_GEN_FILTER pFilter = NULL;
PIP_PATTERN pPattern = NULL;
PIP_PATTERN pMask = NULL;
if(AddressFamily != AF_INET)
    goto Exit;
//
// Allocate memory for the filter
//
pFilter = (PTC_GEN_FILTER)malloc(sizeof (TC_GEN_FILTER));
if(!pFilter)
    goto Exit;
ZeroMemory(pFilter, sizeof(TC_GEN_FILTER));
//
// Allocate memory for the pattern and mask
//
pPattern = (PIP_PATTERN)malloc( sizeof(IP_PATTERN));
pMask = (PIP_PATTERN)malloc( sizeof(IP_PATTERN));
if(!pPattern || !pMask)
    goto Exit;
memset ( pPattern, 0, sizeof(IP_PATTERN) );
pPattern->DstAddr = ((SOCKADDR_IN *)&Address)->sin_addr.s_addr;
pPattern->tcDstPort = htons(Port);
pPattern->ProtocolId = ProtocolId;
memset ( pMask, (ULONG) -1, sizeof(IP_PATTERN) );
//
// Set the source address and port to wildcard
// 0 -> wildcard, 0xFF-> exact match
//
pMask->SrcAddr = 0;
pMask->tcSrcPort = 0;
//
// if the user specified 0 for dest port, dest address or protocol
// set the appropriate mask as wildcard
// 0 -> wildcard, 0xFF-> exact match
//
if(pPattern->tcDstPort == 0)
    pMask->tcDstPort = 0;
if(pPattern->ProtocolId == 0)
    pMask->ProtocolId = 0;
if(pPattern->DstAddr == 0)
    pMask->DstAddr = 0;
pFilter->AddressType = NDIS_PROTOCOL_ID_TCP_IP;
pFilter->PatternSize = sizeof(IP_PATTERN);
pFilter->Pattern = pPattern;
pFilter->Mask = pMask;
//
// Delete any previous instances of the Filter
//
DeleteFilter(ppFilter);
*ppFilter = pFilter;
status = TRUE;
Exit:
if(!status)
{
    printf("Filter Creation Failed\n");
    DeleteFilter(&pFilter);
}
else
    printf("Filter Creation Succeeded\n");
return status;
}

b. Adding the Filter to the TC Flow:
Once a TC Filter structure is obtained using a function similar to the one above, issue a call to TcAddFilter() passing the flowhandle obtained in step #4b and a pointer to the TC_GEN_FILTER structure obtained in step #5a. Store the filter handle returned by TcAddFilter(); let’s call it filterhandle.
You can add multiple filters on the same flow causing different sets of packets matching each filter to get the same QoS characteristics applied to them.

6. At this point, your application is applying QoS on all matching outgoing packets as specified in the TC Filter and TC Flow. Finally, once your purpose is served, make sure you call the respective close calls on all the open TC handles – TcDeletefilter(), TcDeleteFlow(), TcCloseInterface() and TcDeregisterClient().

You can download the full source and binaries of a simple command line tool – tcmonlite, which takes the filter and flow parameters as input, creates TC Flow and Filter, and configures the QoS subsystem with them using the Traffic Control API. All the outgoing traffic on the system matching the filter gets the desired QoS characteristics as long as tcmonlite is running. Go to the Microsoft Connect website, 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 TCMonLite.

This tool can be used in conjunction with the NDIS LWF driver to detect 802.1p tags in the Ethernet header and DSCP in the IP header of packets. Let us know what you think!

-- Hemant Banavar

Introduction to Windows QoS Traffic Control

wndpteam — Tue, 09 Oct 2007 21:05:26 GMT

Disclaimer: Traffic Control (TC) APIs have been marked as deprecated, and will be phased out (eventually removed) when a suitable replacement API is available. No advancements will be made to these APIs (including adding IPv6 support) in their deprecated state; however, application compatibility will be maintained until their eventual removal.

Since the introduction of a QoS platform in Windows 2000, there have been two models for applying prioritization and/or send-rate throttling to TCP/IP and UDP/IP network traffic sent from a Windows PC: host-based and application-based. These terms have been used in QoS documentation such as this recent CableGuy article; however, I acknowledge the meaning of these terms are not immediately obvious.

An application-based model means only the application which owns the socket handle can add/remove/modify a QoS flow for its traffic. Because the application sending data onto the wire (or air) is applying throttling or priority to its own traffic (the connected socket), no elevation of privileges is required. A host-based model means some other process (not the application sending traffic through the socket) on the PC is applying prioritization or throttling to this traffic it doesn't own. Because the process doesn't own the socket handle, elevation of privileges (administrator) is required. While it is certainly possible for the process that owns the socket handle to leverage a host-based model, the added complexity is unnecessary considering socket-based QoS APIs are available for this purpose. A host-based model is a much more complex model than application-based for the following reasons:

The process applying QoS properties to traffic it doesn't own has to run as a service or some other out-of-band means (in typical use cases)
Administrative privileges are required
Because the socket handle is not known, a filter has to be applied to match the traffic of interest, based on: source/destination IPv4 address, source/destination port, and protocol (TCP or UDP)

In Windows, only the Traffic Control (traffic.h/traffic.dll) interface provides programmatic access to a host-based model. There is value gained from this complexity; however. Because this API requires administrative privileges, the caller can specify any arbitrary layer-2 (802.1p) or layer-3 (DSCP) priority value; whereas application-based API models abstract specific priority values with traffic-classes based on established industry standards. It is worth noting that a new policy-based feature has been added to Windows Vista and Windows Server 2008 which enables a host-based model for IT administrators (no coding necessary), which enables significantly richer classification than what TC provides. Policy-based QoS; however, does not provide programmatic access and does not allow for setting layer-2 802.1p tags, only layer-3 DSCP.

Innovation has been focused on application-based APIs such as qWAVE (qos2.h/qwave.dll) to significantly simplify *safely* adding prioritization and throttling to traffic, as well as policy-based mechanisms for host-based needs.

Stay tuned for follow-up posts on how to use TC for adding 802.1p tags to the Ethernet header, DSCP to the IPv4 header, and applying throttling to outgoing traffic.

-- Gabe Frost

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

Detecting 802.1p Priority Tags

wndpteam — Fri, 07 Sep 2007 17:00:00 GMT

Consider a case where a network application calls Windows QoS APIs to add a layer-2 IEEE 802.1Q UserPriority tag (almost always referred to as 802.1p) to outgoing traffic. Ascertaining whether the tag actually got added to an outgoing packet is not as simple as it seems due to the nature of how the Windows network stack is designed, and how framing actually occurs. From an internal implementation perspective, The QoS Packet Scheduler (Pacer.sys in Vista/2008 Server, and Psched.sys in XP/2003 Server) in the network stack merely updates an out-of-band structure (not the actual formed packet) that an 802.1Q UserPriority tag should be added. The specific NDIS structure is NDIS_NET_BUFFER_LIST_8021Q_INFO, which contains member variables for both VlanID and UserPriority, and is passed to the NDIS miniport driver for implementing both priority tagging (UserPriority) and VLAN (VlanId). It is up to the NDIS miniport driver to actually insert the 802.1Q tag into the frame based on these values before transmitting on the wire. A miniport driver will only insert this tag if the feature is supported and enabled in the advanced properties of the NIC driver; typically layer-2 priority tagging is disabled by default.

From a network stack layering perspective, it’s important to understand that Pacer.sys is an NDIS Lightweight Filter (LWF) driver, and will always be inserted above a miniport driver, which will always be the lowest network software in the stack because it communicates directly with the NIC hardware. Also note that network sniffing applications like NetMon and WireShark are also network stack filters, and will always be inserted above the miniport driver. This is important knowledge because it should be clear that taking a network sniff of traffic on the sending PC will never show the tag in a packet (because the tag gets added below the sniffing software). Also, the QoS Packet Scheduler can't know for absolute certainty whether the miniport driver added the tag to the outgoing packet.

What about trying to do a network sniff on the receiving PC? Good question, but also will show the layer-2 tag not present in packets. The reason for this is NDIS developer documentation clearly states that miniport drivers must strip the tag when received, and populate the NDIS_NET_BUFFER_LIST_8021Q_INFO UserPriority and VlanId fields with the values in the tag. This out-of-band structure can then be used by NDIS filter drivers higher up in the stack for implementing these features. The functional reason for stripping the layer-2 tag is because Tcpip.sys will drop any received packet that contains this tag. Therefore, if a misbehaving miniport driver does not strip the tag, the packet will never be received by the user-mode application because it will be dropped internally.

In conclusion:

A network sniffing app on the sending PC will never see a tag
A network sniffing app on the receiving PC will never see a tag

Unless the miniport driver is misbehaving, which will result in dropped packets

Monitoring tagged packets from intermediate network elements (such as a switch) is hard if at all possible

Perhaps a clever SNMP counter could be used, but would depend on the device manufacturer

If you have not came to this conclusion already, the only way to determine whether a layer-2 tag got added on the sending PC and/or received by the receiving PC is to monitor the NDIS_NET_BUFFER_LIST_8021Q_INFO.UserPriority field. Stay tuned for a follow-up post which describes how to do this.

-- Gabe Frost

Windows Rally Demo'd at WinHEC

wndpteam — Wed, 16 May 2007 22:52:00 GMT

I noticed that there was a demo of Rally technologies at the WinHEC keynote the other day, so I created a link to part of the keynote with the Rally demo. Enjoy.

-- Ari Pernick

The Importance of 5GHz Operation for Video

wndpteam — Fri, 09 Feb 2007 19:00:00 GMT

Recently, I read a great article on ZDNet that discusses the challenges IEEE 802.11n faces with 2.4GHz operation. The article is appropriately titled The Consequences of Abandoning the 5GHz Frontier, and discusses some history, backward compatibility, and interference. The important takeaway from this article is if you want a premium experience of video and other Windows Vista scenarios, especially Xbox 360 and Media Center Extender, look for the Certified for Windows Vista logo when purchasing consumer network equipment:

I posted a comment on this article that provides a little more information, which can be found here: http://talkback.zdnet.com/5208-10533-0.html?forumID=1&threadID=29474&messageID=559062

-- Gabe Frost

Wireless Routers That Rock: First Works With Vista Router

wndpteam — Wed, 07 Feb 2007 19:00:00 GMT

Congratulations to D-Link (powered by Ubicom) for being the first ever to acheive a Windows Vista logo for the DIR-655 wireless router. While Buffalo acheived the premium "Certified for Windows Vista" logo, D-Link was first to meet the baseline "Works with Windows Vista" requirements (months ago). What's the difference between the two you ask? First, the requirements for "works with" certification include: QoS, LLTD for rich Network Maps, WCN, Xbox Live, and more. Our baseline suite of tests ensure these devices are extremely robust. To put things in perspective, the *massive* majority of existing consumer networking products *do not* meet the baseline requirements! Remember, our goal is to transform the consumer networking ecosystem, and these devices do.

The requirement differences between the premium logo and baseline are: IPv6 and concurrent dual-band (2.4 & 5 GHz operation); which are huge feats. premium routers must meet all the baseline requirements in addition to the others. Essentially, the premium class routers are for video (both standard-definiton & high-definition) scenarios, and the baseline routers are for everything else.

I'll keep everyone updated on the new devices that acheive the logo. More to talk about very soon...

-- Gabe Frost

Wireless Routers That Rock: First Certified For Vista Router

wndpteam — Tue, 06 Feb 2007 03:47:00 GMT

Congratulations to Buffalo for being the first to acheive a Certified for Windows Vista logo for their dual-band WZR-AG300NH wireless router.

In short, this device passed over eight hours worth of rigerous testing designed to ensure a fantastic experience of Windows Vista scenarios; including HD video streaming from Media Center to Media Center Extenders over wireless! Many folks within core networking worked very hard to create meaningful tests that raise the bar of the consumer networking ecosystem. Certified for Vista wireless routers fully (and correctly) implement: network QoS for differentiating voice/video/best-effort/background traffic, LLTD for producing a rich Network Map, Windows Connect Now for super simple secure setup and adding new devices, IPv6, etc. Glenn Ward on the Windows Rally team, who is responsible for the router logo program, says it best in his email response to Buffalo receiving this honor:

"On behalf of all of us at Microsoft, please accept our congratulations and warmest thanks. Incredible engineering, effort, and determination went into making this happen - outstanding job to all at Buffalo, as well as the internal team who likewise worked tirelessly."

Well said Glenn, thanks for all the hard work!

-- Gabe Frost

QoS Support in Windows

wndpteam — Sat, 03 Feb 2007 00:54:00 GMT

A few months ago, a technical account manager for a customer sent an email to everyone in Windows networking asking about QoS support in Windows. When answering the question, I realized that there was no single document or web page that outlined the level of support and what resources are available for further detail. Because of this, my email response was really extensive and probably overkill for what the customer needed. However, Joseph Davies, who writes as The Cable Guy for TechNet magazine, saw the response and thought it interesting enough to work with folks on the core QoS team on an article called QoS Support in Windows, which was recently published. Also, this article will be published hard copy in this months TechNet magazine. Check it out and let me know what you think or if you have any questions.

-- Gabe Frost

Windows Vista Networking Goodies, Part 2: Device & Service Discovery

wndpteam — Fri, 05 Jan 2007 22:34:00 GMT

In my first post of this series, I talked about Windows Connect Now (WCN) and how easy it is in Windows Vista to discover, configure, and securely connect devices to a wireless network. In this post, I’ll talk about how to discover PCs, devices, and services that are available on the network. In Windows XP, if you wanted to find other PCs (and a limited number of devices) on your network, you went to Network Neighborhood. This interface basically listed all network PCs and, if you enabled Universal Plug-n-Play (UPnP), a small subset of UPnP capable devices such as your router. It’s never a wonderful day in the neighborhood though because the best you can do here is see other networked PCs and browse their file shares. While UPnP eventually provided more service descriptions, those capabilities were not finalized until well after XP shipped, and were almost always disabled by default in devices such as routers and APs. Network Neighborhood doesn’t provide any clear indication of what you can do with a particular PC or device, so we did a bunch of work in Vista to improve.

Windows Vista drastically improves this story by supporting a new concept called function discovery. In Vista’s Network Explorer (the replacement to XP’s Network Neighborhood), devices are discovered using function discovery. Function discovery can find devices using much more efficient, diverse and robust protocols than were available in XP’s Network Neighborhood. These protocols include NetBios, UPnP/SSDP, and Web Services Discovery (WSD). Further, additional providers can be added via a flexible function discovery platform, which means software developers can plug their own discovery methods in for a consistent user experience through the Network Explorer. So how does this relate to Network Neighborhood? In Vista, you can access the Network Explorer by clicking Start\Network. The value of improved function discovery is experienced here. PCs, devices, and their respective services are displayed here in all their glory. In addition to the out-of-box high-resolution icons Vista provides for various device classes, Windows shell extensions can be defined (by the device maker, not the end user) for custom icons and actions (when you right-click or double-click the device). And, network connected devices requiring a device driver can be installed directly from the Network Explorer following a simple plug and play process (the same experience as installing a directly attached peripheral).

In the above snapshot of my Network folder, you’ll see PCs, a network projector, a media sharing service (pictures, music, video), and an un-configured device. In my next post, I’ll talk about IP as just another bus via the PnP-X framework, and how the experience of discovery, installation, and use of network devices is the same as directly attached peripherals. Stay tuned.

-- Gabe Frost