Hello Michael,

On Fri., Apr 16, 2010, Michael SIERCHIO wrote:
>Michael wrote:
>> Referring to the page '/firewall_shaper_edit.php', there are
>> several choices for 'IP Type of Service':
>> 
>>   lowdelay
>>   throughput
>>   reliability
>>   mincost
>>   congestion
>> 
>> It seems that recent RFCs [1] have outdated the classical TOS
>> semantics used by the most recent M0n0wall release. I'm trying
>> to match DSCP class selector 5 (CS5) and am confused about the
>> mapping to the older TOS bits. A document [2] on such mapping
>> helps a little.
>>
>Have you looked at actual traffic to see if these bits are being
>used according to the newer semantics?  In general, I don't see
>this.  This information is useful for routing, esp. fragmented
>packets, but is of very little importance to controlling bandwidth
>utilization to and from your endpoint users.
>
No I haven't looked at actual traffic, but the IP telephones we
have use QoS values in their configuration. Because I've set them
to CS5 for both SIP and RTP traffic, I assume that the bits of TCP
and UDP packets are being correctly manipulated.

>Also remember that m0n0wall doesn't offer priority queuing, it
>uses WFQ2+ - weighted fair queuing that only comes into play
>when queues are full.
>
The way I understand it: If I check the 'lowdelay' TOS value in
my M0n0wall traffic shaping rule, then it will only match packets
with the 'lowdelay' bit set (whatever that is.)

From the wireshark docs, it seems that wireshark uses the same
outdated semantics that M0n0wall uses. I suppose I could workaround
the problem by trial and error, (re)setting the QoS of the phones to
CS5 and then looking at the traffic bits in wireshark.

Wouldn't it be better for M0n0wall to just use the standard as
described in the RFCs, eliminating this problem altogether?

Regards,
Michael