Traffic shaping

NTDEV
1

Hello ,Windows

I need to make a driver to limit bandwidth to/from specific IP
addresses. And I’m trying to choose between TDI and NDIS driver. I
need only to shape TCP connections, but UDP would be good too.
Meanwhile I need to pass PING packets at full speed.

I think It’s easy to do this in TDI layer for TDI_SEND, TDI_RECEIVE
and ClientEventReceive, as there are associated IRPs and they can be
divided into smaller ones and submitted with the delay. But I’m not
sure about ClientEventChainedReceive, as delaying the buffer may
cause performance drop, or timeout at the app side.

At NDIS level I think it’s possible to delay ACK packets, but this
can cause packets retransmission and increased bandwidth usage
(which is opposite to my task) and even connection loss.

Can you guys suggest something? Maybe there are some example
solutions for traffic shaping or documentation available?

Thanks.

–
Best regards,
Yura mailto:xxxxx@mail.zp.ua

2

On Thu, 2004-09-02 at 10:25, Yura wrote:

Hello ,Windows

I need to make a driver to limit bandwidth to/from specific IP
addresses. And I’m trying to choose between TDI and NDIS driver.

I’d recommend an NDIS IM driver, due to the fact that it’s
well-documented and well-supported by Microsoft. If you go the TDI
filter route, I heard that there is a free-as-in-sourceforge firewall
out there that is implemented this way; maybe it’s worth looking at for
reference. Also, check out ndis.com.

At NDIS level I think it’s possible to delay ACK packets, but this
can cause packets retransmission and increased bandwidth usage
(which is opposite to my task) and even connection loss.

This isn’t necessarily true, actually. TCP has algorithms to shape
itself to the apparrent bandwidth of the underlying transport. Read up
on RFC 2581 (www.ietf.org/rfc/rfc2581.txt), RFC 3390
(www.ietf.org/rfc/rfc3390.txt), and (for historical reference, and
because it’s just so well-written) RFC2001
(www.ietf.org/rfc/rfc2001.txt).

Try to understand TCP’s congestion avoidance algorithms, and craft your
drop logic in such a way that it minimizes negative side-effects. Also,
if you want to be very careful, you should test actual implementations
against one another.

Keep in mind that this is how real packet shaping devices work - they
don’t have the luxury of being at the TDI ingress, so they just drop
packets, carefully.

One other thing - I have no idea if it’ll do what you want, but have you
looked at the psched driver that shipped with xp?

HTH.

-sd

–

Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com

3

Sd already spelled out lot of information :). So I would recommend to look
at
“Networking Quality of service and windows operating systems” book. It is
written by an Architect of Microsoft, that spelled out quite a bit of this
traffic shaping/pacing business. There are some changes in XP, as per the
book’s discussion but that is a later thing to worry. Actually the subject
should traffic pacing, not shaping as Sd pointed out. It has a fair amount
of discussion about the pkt scheduler ( an NDIS IM driver, that comes with
OS ). And frankly, I could not find any better place to understand what goes
in side the pkt sheduler :slight_smile:

I hate redundancy, but sometime it brings the context, so I would also say
IM is the best bet.

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Steve Dispensa
Sent: Thursday, September 02, 2004 11:35 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Traffic shaping

On Thu, 2004-09-02 at 10:25, Yura wrote:

Hello ,Windows

I need to make a driver to limit bandwidth to/from specific IP
addresses. And I’m trying to choose between TDI and NDIS driver.

I’d recommend an NDIS IM driver, due to the fact that it’s
well-documented and well-supported by Microsoft. If you go the TDI
filter route, I heard that there is a free-as-in-sourceforge firewall
out there that is implemented this way; maybe it’s worth looking at for
reference. Also, check out ndis.com.

At NDIS level I think it’s possible to delay ACK packets, but this
can cause packets retransmission and increased bandwidth usage
(which is opposite to my task) and even connection loss.

This isn’t necessarily true, actually. TCP has algorithms to shape
itself to the apparrent bandwidth of the underlying transport. Read up
on RFC 2581 (www.ietf.org/rfc/rfc2581.txt), RFC 3390
(www.ietf.org/rfc/rfc3390.txt), and (for historical reference, and
because it’s just so well-written) RFC2001
(www.ietf.org/rfc/rfc2001.txt).

Try to understand TCP’s congestion avoidance algorithms, and craft your
drop logic in such a way that it minimizes negative side-effects. Also,
if you want to be very careful, you should test actual implementations
against one another.

Keep in mind that this is how real packet shaping devices work - they
don’t have the luxury of being at the TDI ingress, so they just drop
packets, carefully.

One other thing - I have no idea if it’ll do what you want, but have you
looked at the psched driver that shipped with xp?

HTH.

-sd

–

Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Delay at NDIS level. After all, TDI filters are not documented and thus are
not a way to go (unless you want to have unsolvable interop issue with a
similar product).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Yura”
To: “Windows System Software Devs Interest List”
Sent: Thursday, September 02, 2004 7:25 PM
Subject: [ntdev] Traffic shaping

> Hello ,Windows
>
> I need to make a driver to limit bandwidth to/from specific IP
> addresses. And I’m trying to choose between TDI and NDIS driver. I
> need only to shape TCP connections, but UDP would be good too.
> Meanwhile I need to pass PING packets at full speed.
>
> I think It’s easy to do this in TDI layer for TDI_SEND, TDI_RECEIVE
> and ClientEventReceive, as there are associated IRPs and they can be
> divided into smaller ones and submitted with the delay. But I’m not
> sure about ClientEventChainedReceive, as delaying the buffer may
> cause performance drop, or timeout at the app side.
>
> At NDIS level I think it’s possible to delay ACK packets, but this
> can cause packets retransmission and increased bandwidth usage
> (which is opposite to my task) and even connection loss.
>
> Can you guys suggest something? Maybe there are some example
> solutions for traffic shaping or documentation available?
>
> Thanks.
>
> –
> Best regards,
> Yura mailto:xxxxx@mail.zp.ua
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com