how about implement network bandwidth shaping for win7?

[Fei Zhang]

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

[Maxim S. Shatskih]

Post by Fei Zhang
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.

[Pavel A.]

Post by Maxim S. Shatskih

Post by Fei Zhang
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

Post by Maxim S. Shatskih
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.

Post by Maxim S. Shatskih
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

[Maxim S. Shatskih]

Post by Pavel A.

Post by Maxim S. Shatskih
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.

Post by Pavel A.
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.

[Pavel A.]

Post by Maxim S. Shatskih

Post by Pavel A.

Post by Maxim S. Shatskih
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.

Post by Pavel A.
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

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

[Fei Zhang]

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