On Sun, 6 Aug 2006 00:51:31 -0400, you wrote:

>I had someone from a forum remote into my Monowall and noticed I had "low
>delay" set for TOS for the incoming data.  For some reason that low delay
>TOS setting overrode my low BW setting.  I just assumed I was supposed to
>have the low delay set for VoIP.  But that is what was causing my incoming
>audio data to still sound good and made me think the pipe wasn't working.
>
>Interestingly enough, the low delay setting for outgoing data did not over
>ride the low BW setting.  Even with TOS low delay on, when I set the
>outgoing data to 25 Kbs, I had stuttering audio. 
>
>Low delay TOS seemed to override the BW setting for incoming VoIP data, but
>not for outgoing VoIP data.  I don't know why.  So the question is, since
>this is for VoIP, should I have TOS low delay on or off for VoIP data?

So far as I know, the ToS flag are just like the TCP flags.  They are used to
selectively apply a rule to specific packets and do not actually change any of
the flags.  I always left them set to "don't care".  In order to select my VoIP
traffic, I used the internal IP address of my VoIP client which is fixed.

If the traffic shaping rules only apply to traffic incoming on the interface the
rules is written on and your rules were all on the WAN interface, then none of
them applied to your outgoing traffic.  See below.

>"To shape outgoing traffic, the rule has to be on the LAN or OPT interface.
>To shape incoming traffic, the rule has to be on the WAN interface.  In
>practice this means the direction field has to always
>be set to "In" and the rule has to be placed on a specific interface to set
>the direction."
>
>Dave, regarding what you said about the outgoing and incoming traffic and
>the interfaces, I have been confused on this also.
>
>I saw something where a couple writers say all the shaper rules were to be
>on the WAN interface.  But what you say about using the LAN and OPT1
>interfaces makes sense too.  It's sometimes difficult to know for sure what
>interfaces to use for the shaper rules.  Would be good to hear from other on
>this.

I have read statements saying both that all rules need to be on the WAN
interface and that rules only apply to packets incoming on the interface the
rule is attached to so I was also confused.  It would be easier if all rules
could be written for both directions and on one interface but I was never able
to get it to work that way.

Originally when I tested this, I was using the system as a filtering bridge so I
only had to deal with one OPT interface.  To test it, I used PING to measure
latency to the gateway on the other end of the DSL link.  Then I adjusted the
incoming and outgoing queue delays separately and made sure they were both
reflected in the PING latency.  Originally with all rules on the WAN interface
as recommended, the outgoing rule did not work.  Moving the outgoing rule to the
OPT interface and setting its direction to incoming fixed it and gave the
intended result of independent traffic filtering on incoming and outgoing
traffic.

I am using pfsense now but even with a different traffic shaper I found the
setup to be very similar if more complicated.  I lament the loss of adjustable
queue delay though which made testing easier.