QoS in Wi-Fi driver and winsock

I'm going to add multimedia (WME) support to a 802.11 miniport driver.
What is the best way to expose this to applications and Windows (XP+)?
The WMM whitepaper on wi-fi.org states that newly developed apps should
use GQOS, as defined in winsock2 API.
But MSDN and DDK are quite fuzzy in this area
Basically I want to track WSAIocltl(SET_QOS) on sockets,
and pass the entire QoS struct to my driver. So I need also track opening
and closing sockets. Also the interface should be seen as QoS enabled in
WSAEnumProtocols, WSAGetQOSByName and so on.
So, what I need to add to the miniport driver? a winsock
LSP hook, a TC hook, or RSVPSP hook or all of them?

Is it a good idea to provide WSAGetQOSByName, so apps
could get QoS templates provisioned by network administrator, and select
the most suitable? Or apps won't use this and will just go ahead and set
QoS by traffic type, ot specifying qualitative parameters.
Of course I'd like to implement this in the most generic way, to
support also other device types : cellular WWAN, DOCSIS and so on.

Please advice...

With regards
--PA

Pavel !
Without any other propositions, I'm back with advise to use LSP, which parse
and send data to your protocol driver which in turn send to miniport.
Arkady

"Pavel A." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I'm going to add multimedia (WME) support to a 802.11 miniport driver.
> What is the best way to expose this to applications and Windows (XP+)?
> The WMM whitepaper on wi-fi.org states that newly developed apps should
> use GQOS, as defined in winsock2 API.
> But MSDN and DDK are quite fuzzy in this area
> Basically I want to track WSAIocltl(SET_QOS) on sockets,
> and pass the entire QoS struct to my driver. So I need also track opening
> and closing sockets. Also the interface should be seen as QoS enabled in
> WSAEnumProtocols, WSAGetQOSByName and so on.
> So, what I need to add to the miniport driver? a winsock
> LSP hook, a TC hook, or RSVPSP hook or all of them?
>
> Is it a good idea to provide WSAGetQOSByName, so apps
> could get QoS templates provisioned by network administrator, and select
> the most suitable? Or apps won't use this and will just go ahead and set
> QoS by traffic type, ot specifying qualitative parameters.
> Of course I'd like to implement this in the most generic way, to
> support also other device types : cellular WWAN, DOCSIS and so on.
>
> Please advice...
>
> With regards
> --PA
>
>

Akady thanks,
but I have at least two doubts about LSP:
1. It looks too complicated and not robust. LSP database in the registry is used
by all kinds of s/w - from viruses to antiviruses... you know.
I'd like to avoid it if possible.
2. How about kernel side traffic. LSP won't catch it, correct?

--PA

"Arkady Frenkel" <arkadyf@hotmailxdotxcom> wrote in message news:(E-Mail Removed)...
> Pavel !
> Without any other propositions, I'm back with advise to use LSP, which parse
> and send data to your protocol driver which in turn send to miniport.
> Arkady
>
> "Pavel A." <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > I'm going to add multimedia (WME) support to a 802.11 miniport driver.
> > What is the best way to expose this to applications and Windows (XP+)?
> > The WMM whitepaper on wi-fi.org states that newly developed apps should
> > use GQOS, as defined in winsock2 API.
> > But MSDN and DDK are quite fuzzy in this area
> > Basically I want to track WSAIocltl(SET_QOS) on sockets,
> > and pass the entire QoS struct to my driver. So I need also track opening
> > and closing sockets. Also the interface should be seen as QoS enabled in
> > WSAEnumProtocols, WSAGetQOSByName and so on.
> > So, what I need to add to the miniport driver? a winsock
> > LSP hook, a TC hook, or RSVPSP hook or all of them?
> >
> > Is it a good idea to provide WSAGetQOSByName, so apps
> > could get QoS templates provisioned by network administrator, and select
> > the most suitable? Or apps won't use this and will just go ahead and set
> > QoS by traffic type, ot specifying qualitative parameters.
> > Of course I'd like to implement this in the most generic way, to
> > support also other device types : cellular WWAN, DOCSIS and so on.
> >
> > Please advice...
> >
> > With regards
> > --PA
> >
> >
>
>

"Pavel A." <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> Akady thanks,
> but I have at least two doubts about LSP:
> 1. It looks too complicated and not robust. LSP database in the registry
is used
> by all kinds of s/w - from viruses to antiviruses... you know.
> I'd like to avoid it if possible.
So you need to use old method - hooking of winsock , not nice too

> 2. How about kernel side traffic. LSP won't catch it, correct?
>
Sure not

Arkady

> --PA
>
> "Arkady Frenkel" <arkadyf@hotmailxdotxcom> wrote in message
news:(E-Mail Removed)...
> > Pavel !
> > Without any other propositions, I'm back with advise to use LSP, which
parse
> > and send data to your protocol driver which in turn send to miniport.
> > Arkady
> >
> > "Pavel A." <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > I'm going to add multimedia (WME) support to a 802.11 miniport driver.
> > > What is the best way to expose this to applications and Windows (XP+)?
> > > The WMM whitepaper on wi-fi.org states that newly developed apps
should
> > > use GQOS, as defined in winsock2 API.
> > > But MSDN and DDK are quite fuzzy in this area
> > > Basically I want to track WSAIocltl(SET_QOS) on sockets,
> > > and pass the entire QoS struct to my driver. So I need also track
opening
> > > and closing sockets. Also the interface should be seen as QoS enabled
in
> > > WSAEnumProtocols, WSAGetQOSByName and so on.
> > > So, what I need to add to the miniport driver? a winsock
> > > LSP hook, a TC hook, or RSVPSP hook or all of them?
> > >
> > > Is it a good idea to provide WSAGetQOSByName, so apps
> > > could get QoS templates provisioned by network administrator, and
select
> > > the most suitable? Or apps won't use this and will just go ahead and
set
> > > QoS by traffic type, ot specifying qualitative parameters.
> > > Of course I'd like to implement this in the most generic way, to
> > > support also other device types : cellular WWAN, DOCSIS and so on.
> > >
> > > Please advice...
> > >
> > > With regards
> > > --PA
> > >
> > >
> >
> >
>
>

"Ganaka" <(E-Mail Removed)> wrote in message news:(E-Mail Removed) om...
> Pavel,
> Did you have a chance to implement WMM in your miniport? I am doing
> the same, but for some reason I don't get the 802.1p priority codes
> all the time (it depends on the AP used). Any ideas?
>
> Thanks,
> -Ganaka

Of course we will support WMM. But it is media specific.
I'm looking for media independent QoS support, that will cover
also DSL/ATM and docsis.

Winsock 2 API already defines interfaces for detecting and specifying
QoS for applications - but it seems that nobody knows how exactly
the MAC driver should expose it's QoS caps to be seen by OS and winsock.

Is there some standard NDIS OIDs or characheristics, registry settings?
Do I need to write some plugin? Mistery, mistery...
--PA

Ah. If the AP does not support WMM, you won't get it.
The only idea here is to get a compatible AP.
And test that your driver doesn't crash with any AP.

"Pavel A." <(E-Mail Removed)> wrote in message news:#(E-Mail Removed)...
> "Ganaka" <(E-Mail Removed)> wrote in message news:(E-Mail Removed) om...
> > Pavel,
> > Did you have a chance to implement WMM in your miniport? I am doing
> > the same, but for some reason I don't get the 802.1p priority codes
> > all the time (it depends on the AP used). Any ideas?
> >
> > Thanks,
> > -Ganaka
>
> Of course we will support WMM. But it is media specific.
> I'm looking for media independent QoS support, that will cover
> also DSL/ATM and docsis.
>
> Winsock 2 API already defines interfaces for detecting and specifying
> QoS for applications - but it seems that nobody knows how exactly
> the MAC driver should expose it's QoS caps to be seen by OS and winsock.
>
> Is there some standard NDIS OIDs or characheristics, registry settings?
> Do I need to write some plugin? Mistery, mistery...
> --PA
>
>
>

We are currently investigating this.
Seems like at some layer, we need to persuade tcpip to add the 802.1p/q tag
to packets, but we don't know how to talk to this layer.

--PA

"Ganaka" wrote:
> Pavel,
> My questions is more on the basics side. In order to support QoS, I
> need to get the priority information per packet (using
> NDIS_PER_PACKET_INFO_FROM_PACKET). However, in most of the cases the
> packet priority is 'best effort'. This is while running WiFi tests
> (using Chariot and all). I don't understand what could be wrong...
>
> According to DDK documentation, the miniport driver must support
> OID_GEN_MAC_OPTIONS and return NDIS_MAC_OPTION_8021P_PRIORITY &
> NDIS_MAC_OPTION_8021Q_VLAN flags in response. This I am doing, yet the
> packet priorities are not being passed down properly.
>
> I am running out of ideas. Does anyone know what could be the cause?
>
> Thanks,
> -Ganaka

Ganaka,
U are right. Probably make sure, 'Packet' is refreshed everytime before
making the call.
It works well, and consistent.

Which is the vendor card and AP u are using with.

Arul V raj.
Atheros Communications

"Ganaka" wrote:

> Pavel,
> My questions is more on the basics side. In order to support QoS, I
> need to get the priority information per packet (using
> NDIS_PER_PACKET_INFO_FROM_PACKET). However, in most of the cases the
> packet priority is 'best effort'. This is while running WiFi tests
> (using Chariot and all). I don't understand what could be wrong...
>
> According to DDK documentation, the miniport driver must support
> OID_GEN_MAC_OPTIONS and return NDIS_MAC_OPTION_8021P_PRIORITY &
> NDIS_MAC_OPTION_8021Q_VLAN flags in response. This I am doing, yet the
> packet priorities are not being passed down properly.
>
> I am running out of ideas. Does anyone know what could be the cause?
>
> Thanks,
> -Ganaka
>
> "Pavel A." <(E-Mail Removed)> wrote in message news:<#(E-Mail Removed)>...
> > "Ganaka" <(E-Mail Removed)> wrote in message news:(E-Mail Removed) om...
> > > Pavel,
> > > Did you have a chance to implement WMM in your miniport? I am doing
> > > the same, but for some reason I don't get the 802.1p priority codes
> > > all the time (it depends on the AP used). Any ideas?
> > >
> > > Thanks,
> > > -Ganaka
> >
> > Of course we will support WMM. But it is media specific.
> > I'm looking for media independent QoS support, that will cover
> > also DSL/ATM and docsis.
> >
> > Winsock 2 API already defines interfaces for detecting and specifying
> > QoS for applications - but it seems that nobody knows how exactly
> > the MAC driver should expose it's QoS caps to be seen by OS and winsock.
> >
> > Is there some standard NDIS OIDs or characheristics, registry settings?
> > Do I need to write some plugin? Mistery, mistery...
> > --PA
>