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 <[email protected]> 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:[email protected]] >>> 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 >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to >>> [email protected]. >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to >>> [email protected]. >>> >>> >> >> ------------------------------------------------------------------------------ >> 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to >> [email protected]. > > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > [email protected]. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [email protected].
