Hi Michael,
Sorry to be unclear...
Late last week, when the symptom was exhibiting itself (when one of my
co-workers trying to download half of the Internet), I defeated Traffic Shaping
altogether using the pulldown option menu on the Firewall page. This pulldown,
which includes selections for "htb" and "hfsc," also has a "Disabled" option.
Last week, the moment we set this pulldown to "Disabled," the incoming audio
dropouts completely went away.
At present, with Lonnie's recent suggestion, I've reset this pulldown to htb,
and entered a Downlink Speed of 0 K bits-per-second.
Cordially,
Dan
-----Original Message-----
From: "Michael Knill" <michael.kn...@ipcsolutions.com.au>
Sent: Saturday, March 2, 2013 11:55pm
To: "AstLinux Users Mailing List" <astlinux-users@lists.sourceforge.net>
Subject: Re: [Astlinux-users] QoS and Traffic Shaping
Hi Dan
When you say that you defeated the Traffic Shaping altogether, did you set it
to 0K or something else?
Regards
Michael Knill
On 03/03/2013, at 7:59 AM, Dan Ryson <d...@ryson.org> wrote:
> Hello Lonnie,
>
> Thanks for the advice. I'll give your 0 K bits-per-second "Downlink"
> setting a try. I suspect that'll work for us based on the following
> observation, made shortly after I send my most recent e-mail.
>
> While downloading a bunch of files at a high bandwidth and listening to
> drop-outs on incoming voice traffic, we tried a wide range of "Downlink"
> speeds, from 500 K all the way up to 30,000 K. (Our advertised rate is
> 27/7.) Because the severity of drop-outs lessened but persisted at the
> higher rate settings, we tried defeating Traffic Shaping all together.
> As soon as we did, the dropouts were eliminated. (Kind of ironic...)
>
> Dan
>
>
>
> On 03/01/2013 04:48 PM, Lonnie Abelbeck wrote:
>> Hi Dan,
>>
>> I would suggest you try setting the "Downlink Speed:" to "0" K
>> bits-per-second, and give that a try.
>>
>> This special case will disable all downlink 'shaping', which for the
>> downlink is simply dropping packets coming in faster than the rate specified.
>>
>> The only real true 'shaping' can be done on the Uplink where packets are
>> prioritized before being sent. Even with the "Uplink Speed" at the
>> advertised rate, there is about 25% headroom for VoIP traffic built-in. For
>> example, with a 4 Mbps UP connection and "Uplink Speed:" set to "4000" K
>> bits-per-second, HTTP (low priority) traffic UP will be limited to about 3
>> Mbps and about 1 Mbps headroom is reserved for VoIP.
>>
>> My guess is your such low Downlink Speed and the new "more accurate"
>> downlink shaping, it is dropping downlink VoIP packets when that threshold
>> is met.
>>
>> Previous to AstLinux 1.1.0 the method used to shape the downlink did not
>> work properly for all ethernet NIC's, the current method works for all NIC's
>> we have access to test.
>>
>> In general, some may disagree with me, but 'shaping' Downlink traffic by
>> dropping packets in a VoIP environment seems like a bad idea. Of course
>> there may be special cases when shaping Downlink traffic is fine,
>> particularly if it is primarily TCP traffic and not VoIP.
>>
>> Personally on my Cable Modem - AstLinux setup, my "Downlink Speed:" is set
>> to "0" K bits-per-second and my "Uplink Speed:" is set to my typical real
>> speed when traffic shaping is disabled. I use "htb" as well.
>>
>> Lonnie
>>
>>
>>
>>
>> On Feb 28, 2013, at 11:39 AM, Dan Ryson wrote:
>>
>>> All,
>>>
>>> I'm reviving this old thread to inquire whether recent changes in 1.1.0
>>> traffic shaping (outlined below) might affect how best to adjust specific
>>> QOS settings.
>>>
>>> ChangeLog 1.1.0_1 includes this little nugget:
>>>
>>> AIF traffic-shaping, incoming (ingress) traffic shaping now uses "avrate"
>>> for more accurate shaping.
>>> Note: This new approach is somewhat more aggressive than previously,
>>> increasing the limit may be desired.
>>>
>>> I'm asking because we're experiencing a new symptom whenever someone in the
>>> office downloads large files at high speeds. We experience periodic (every
>>> 1.5 seconds or so) audio dropouts on incoming voices only. This is a new
>>> symptom for us that we would be delighted to fix.
>>>
>>> We're using "htb" with what we believe to be very conservative settings:
>>>
>>> * UP/DOWN speeds are set at 30% of "advertised" ISP values. (We've tried
>>> less radical settings too.)
>>> * VoIP UDP Ports are defined to match those specified in RTP.conf
>>> * DSCP markings are set in sip.conf as Lonnie recommended below
>>>
>>> Any thoughts?
>>>
>>> Thanks,
>>>
>>> Dan
>>>
>>> -----Original Message-----
>>> From: Lonnie Abelbeck [mailto:li...@lonnie.abelbeck.com]
>>> Sent: Saturday, November 17, 2012 11:58 PM
>>> To: AstLinux Users Mailing List
>>> Subject: Re: [Astlinux-users] QoS and Traffic Shaping
>>>
>>> Michael,
>>>
>>> Because of historical reasons, the Firewall tab -> VoIP UDP Ports: field
>>> needs to have a value, so use the RTP range so it has a value and makes sure
>>> that UDP range has priority. But yes, the DSCP values would be used
>>> otherwise.
>>>
>>> Personally I would not re-write DSCP values via the switch unless you have
>>> problems that can't be solved any other way. Note that SHAPER_P2P_HOSTS can
>>> contain CIDR values as well as single IP addresses to control bandwidth
>>> hogs, though some would look upon that as too generalized and heavy handed
>>> as well.
>>>
>>>> So am I correct in saying that EF will go in High Priority and CS3 in
>>> medium priority.
>>>
>>> Yes.
>>>
>>>> It says SIP Signalling is default for Medium Priority. Is that
>>> classification via Port 5060:5064 on UDP (and TCP/TLS) or via CS3 DSCP
>>> classification (or both)?
>>>
>>> Not sure what you are asking. In the traffic shaper plugin, the
>>> classify_by_host (SHAPER_P2P_HOSTS) and classify_by_port (SHAPER_xxx_PORTS)
>>> are applied first, and finally classify_by_dscp_class for any remaining
>>> unclassified.
>>>
>>> I know people that use the IP Phone's DATA ports for PC's, so the voice is
>>> placed on a VLAN and the DATA is untagged, using different subnets existing
>>> on the same wire, here you can use the switch's 802.1p VLAN priority's to
>>> prioritize traffic before it even hits the edge where the AstLinux traffic
>>> shaper resides. In this case PC file server access and such can effect
>>> voice quality over the local drop without some help from the switch.
>>>
>>> Keep in mind traffic shaping is as much of an art as it is a science.
>>>
>>> Lonnie
>>>
>>>
>>> On Nov 17, 2012, at 8:55 PM, Michael Knill wrote:
>>>
>>>> Thanks Lonnie. Oops I didn't look at the config file.
>>>>
>>>> So from what you are saying, I don't even need to set these ports if I am
>>> setting DSCP correctly. In fact would it be better if I actually left them
>>> blank?
>>>> I intend on creating QoS Trust boundaries which I can do on the switch.
>>> This will rewrite all DSCP to 0 for untrusted hosts (PC's) and the DSCP is
>>> trusted for IP Phones.
>>>> Of course Soft Phones break this concept.
>>>>
>>>> So am I correct in saying that EF will go in High Priority and CS3 in
>>> medium priority. It says SIP Signalling is default for Medium Priority. Is
>>> that classification via Port 5060:5064 on UDP (and TCP/TLS) or via CS3 DSCP
>>> classification (or both)?
>>>> Thanks very much for your help as always.
>>>>
>>>> Regards
>>>> Michael Knill
>>>>
>>>>
>>>>
>>>>
>>>> On 18/11/2012, at 1:06 PM, Lonnie Abelbeck wrote:
>>>>
>>>>> Michael,
>>>>>
>>>>> Personally I use "htb", seems to give me the best results. I think the
>>> newer 'hfsc' might work well for general mixed traffic, but I have found
>>> that 'hfsc' is too slow to adjust for VoIP to be its best.
>>>>> Personally I set my Down/Up speed right at my advertised values (28 M / 4
>>> M), if you want to knock them down by 5% that would be fine, a good starting
>>> point. This will automatically leave about 20% of the up-link free for the
>>> highest priority class. If you need more than 20% for your SIP traffic,
>>> then you can reduce you up-link speed value.
>>>>> Regardless you should test by calling yourself via an
>>> inside-to-outside-to-inside call, place yourself on hold, listen to the hold
>>> music. Then run a speed-test, the up-link test will show the worst case
>>> scenario.
>>>>> #1 ) In this day and age much of the traffic will be classified by DSCP
>>> markings by default, which is honored, but be sure to set those in sip.conf:
>>>>> --
>>>>> tos_sip=cs3 ; Sets TOS for SIP packets.
>>>>> tos_audio=ef ; Sets TOS for RTP audio packets.
>>>>> tos_video=af41 ; Sets TOS for RTP video packets.
>>>>> tos_text=af41 ; Sets TOS for RTP text packets.
>>>>> --
>>>>> https://wiki.asterisk.org/wiki/display/AST/IP+Quality+of+Service
>>>>>
>>>>> Setting the SIP RTP port range is still fine, and what we had to do in
>>> the Asterisk 1.2 days.
>>>>> You can also do some tweaks here:
>>>>>
>>>>>> From the Network tab -> Firewall Plugins: [ traffic-shaper ]
>>>>> You can define/tweak some of the priorities, but the defaults should be
>>> good for the typical situation. Should you have a NAS doing offsite backups
>>> or such, you may want to define SHAPER_P2P_HOSTS.
>>>>>
>>>>> #2) A 5% reduction is fine, you could start with no reduction and start
>>> from there. Each ISP probably has it's own sweet spot. Be sure to test.
>>>>>
>>>>> #3) Downlink shaping is not as critical since the bottleneck is usually
>>> on the up-link, but it simply discards bursts of data higher than the limit.
>>>>> It seems to me that getting quality voice connections is easier today
>>>>> than it was a few years ago. Possibly the bigger pipes are the
>>>>> reason, possibly some traffic shaping is done by the ISP ? I don't
>>>>> use IAX anymore. :-) Also people are now so used to cell phones,
>>>>> crappy audio is tolerated more than it was in the past. :-)
>>>>>
>>>>> Regardless enabling traffic shaping is good practice, if for nothing else
>>> to control buffer-bloat.
>>>>> Bufferbloat
>>>>> http://en.wikipedia.org/wiki/Bufferbloat
>>>>>
>>>>> Lonnie
>>>>>
>>>>> PS: We use 'tc' in the traffic shaper plugin to perform the shaping.
>>>>>
>>>>>
>>>>> On Nov 17, 2012, at 3:53 PM, Michael Knill wrote:
>>>>>
>>>>>> To the group
>>>>>>
>>>>>> I realise that I don't completely understand how the traffic shaping
>>> works on AstLinux and I really need to.
>>>>>> I have set the following:
>>>>>>
>>>>>> Type - I am using hfsc which I assume is the best Downlink speed - I
>>>>>> am setting this to slightly less than than my DSL modems reported
>>>>>> speed e.g. 95% Uplink speed - I am setting this to slightly less
>>>>>> than than my DSL modems reported speed e.g. 95% VoIP UDP Ports -
>>>>>> 16384:16639. The same as I have set in rtp.conf
>>>>>>
>>>>>> My questions are:
>>>>>>
>>>>>> 1) Does the script only use the VoIP ports for queue classification. It
>>> appears that even though I have the range set in rtp.conf, it only affects
>>> my allocated port and not the destination port to my Service provider which
>>> is not in this range? Wont this mean that I am not prioritising rtp on my
>>> uplink? Can I force symmetrical RTP port allocation?
>>>>>> 2) Is 95% ok for the reduction. Does anyone use a different formula
>>>>>> 3) How does the Downlink traffic shaping work? Does it just restrict the
>>> traffic flow of non VoIP traffic (e.g. not in the VoIP UDP Port Range) to
>>> fit the Downlink traffic shaping envelope?
>>>>>> What is everyone else doing?
>>>>>>
>>>>>> Regards
>>>>>> Michael Knill
>>>
>>> ----------------------------------------------------------------------------
>>> --
>>> Monitor your physical, virtual and cloud infrastructure from a single web
>>> console. Get in-depth insight into apps, servers, databases, vmware, SAP,
>>> cloud infrastructure, etc. Download 30-day Free Trial.
>>> Pricing starts from $795 for 25 servers or applications!
>>> http://p.sf.net/sfu/zoho_dev2dev_nov
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Astlinux-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to
>>> pay...@krisk.org.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_feb
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Astlinux-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to
>>> pay...@krisk.org.
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> Astlinux-users mailing list
>> Astlinux-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
>> pay...@krisk.org.
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
