how about implement network bandwidth shaping for win7?

I wanna implement a traffic shaper for win7 to limit some application's
downloading speed.If I write a ndis intermediate driver and throttle the
receiving speed from the IM driver, the IM driver should put the
application's rx frames into a queue to limit its receiving speed, that will
use out the miniport NIC driver's rx buffer so that the NIC will send pause
frame to the partner. Then all other application's receiving performance
will decline too. This is not what I expect. It seems that Winsock Kernel
and Windows Filtering Platform can't be used to shape traffic, limit
receiving speed. I know some firewall for xp uses TDI driver to shape
traffic, but there is no TDI on win7 now. What should I do?
Any suggestions or any kind of keywords will be appreciated. Thanks a lot
in advance.



__________ Information from ESET NOD32 Antivirus, version of virus signature database 5241 (20100630) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

> use out the miniport NIC driver's rx buffer so that the NIC will send pause
> frame to the partner.

There is no such thing as "pause frame" sent by the NIC. This is all done at the TCP level.

What you can really do is to really emulate low bandwidth, i.e. delay - or even drop altogether - the packets belonging to some "pipe", so that the total data flow through a pipe will be below the limit.

If done properly, this will properly influence the TCP's slow start/congestion avoidance algorithm and properly decrease the download speed.

Or you can use the OS's PSCHED, which is now - a pity - manageable only from the admin tools, not from the app's code.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

"Maxim S. Shatskih" <> wrote in message
news:...
>> use out the miniport NIC driver's rx buffer so that the NIC will send
>> pause
>> frame to the partner.
>
> There is no such thing as "pause frame" sent by the NIC. This is all done
> at the TCP level.

This is 802.3x flow control
http://en.wikipedia.org/wiki/Ethernet_flow_control

> What you can really do is to really emulate low bandwidth, i.e. delay - or
> even drop altogether - the packets belonging to some "pipe", so that the
> total data flow through a pipe will be below the limit.

.... and this can cause re-sends on TCP level :-( May work with UDP.

> Or you can use the OS's PSCHED, which is now - a pity - manageable only
> from the admin tools, not from the app's code.
>

There's really no some API for pacer (or whatever its name)? Pity, indeed.

Regards,
-- pa

>> What you can really do is to really emulate low bandwidth, i.e. delay - or
>> even drop altogether - the packets belonging to some "pipe", so that the
>> total data flow through a pipe will be below the limit.
>
> ... and this can cause re-sends on TCP level :-( May work with UDP.

This is how FreeBSD's "dummynet" works actually. Resends will occur, but this is OK - on a slow network, they will occur anyway. Just don't forget to send SQ when the packet is discarded.

> There's really no some API for pacer (or whatever its name)? Pity, indeed.

Once it was controllable by QoS bits in IP header, but now MS abandoned this and it is only controllable now using some admin tools, so the app writers cannot hardcode the packet priority.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

"Maxim S. Shatskih" <> wrote in message
news:...
>>> What you can really do is to really emulate low bandwidth, i.e. delay -
>>> or
>>> even drop altogether - the packets belonging to some "pipe", so that the
>>> total data flow through a pipe will be below the limit.
>>
>> ... and this can cause re-sends on TCP level :-( May work with UDP.
>
> This is how FreeBSD's "dummynet" works actually. Resends will occur, but
> this is OK - on a slow network, they will occur anyway. Just don't forget
> to send SQ when the packet is discarded.
>
>> There's really no some API for pacer (or whatever its name)? Pity,
>> indeed.
>
> Once it was controllable by QoS bits in IP header, but now MS abandoned
> this and it is only controllable now using some admin tools, so the app
> writers cannot hardcode the packet priority.

IIRC, the diffserv DSCP field take over the 3 QOS bits in the 802.1p/Q
ethernet header.
the value in this field is index into table of TC "flows". And IIRC there is
some API to configure the "flows".
Haven't touched this stuff for long time. They now have MDSN forum for QOS:
msdn.en-us.networkqoswave

Regards,
-- pa

> --
> Maxim S. Shatskih
> Windows DDK MVP
>
> http://www.storagecraft.com
>

Hi Pavel, Maxim,
Thank you all, your suggestions are very helpful. I'm studying and revising
the WFP driver to shape traffic now. Thanks for your kind help.
BR,
Fei Zhang



__________ Information from ESET NOD32 Antivirus, version of virus signature database 5244 (20100701) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com