Hi Paul, Keep in mind that, at least in my experience, adjusting the bucket size changes how much the traffic can burst. If you don't want any bursting, set it as low as possible, which I believe is 0.001. Maxing the limit-at value is probably something you want to set. This is what other vendors call CIR, or Committed Information Rate, which is the guaranteed amount of traffic that queue can get. Then the Max-limit is the PIR, or Peak Information Rate. Give Voice a CIR of say 1M, and PIR of 20M, then give the "other" traffic a CIR of whatever you like (or nothing) and the same PIR of 20M. This should be all that is required. By reducing the number of tokens available overall, it may reduce the initial delay in prioritising Voice over other traffic. Regards, Philip Loenneker | Network Engineer | TasmaNet 40-50 Innovation Drive, Dowsing Point, Tas 7010, Australia P: 1300 792 711 philip.loenneker@tasmanet.com.au www.tasmanet.com.au -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Paul Julian Sent: Monday, 17 December 2018 1:11 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] QOS Philip and all, I have watched the video, it's a good watch actually and very informative, I do recommend that if you haven't watch it you should do, it's explains some great things, don't mind that Splynx product either...... It seems that that HTB system is pretty good and would, if configured correctly, help with MEF standard Ethernet links such as AAPT and Telstra where bursting is allowed before the interface is rate limited by the carrier, so knowing how much to burst and for how long is pretty important, it's good to see an option to help with this as previously you simply had to rate limit your connections slightly lower than the actual link speed to have any real success. In our systems we own the dslams and everything needed to provide the connection to customers, all we need to do is make sure voice is prioritised over everything else. Previously we have had good success with a simple strategy of a parent interface queue and two child queues, one for voice and one for everything else (no-mark). Simply setting the priorities accordingly worked pretty well, however we have been having some issues of late which may be after an update somewhere possibly. I would like to try and understand more about the new bucket size option and have read a fair bit about it now but just can't get my head around it.....I believe that with some more understanding this could help with our requirements. Ultimately I suppose I need the voice queue to be able to borrow as many tokens as it needs from the parent and the other traffic queue to get none, or less I suppose. In the scenario we currently have we would have for example: Parent Queue - max-limit=20M priority=8 Other Queue - max-limit=20M priority=8 packet-mark=no-mark Voice Queue - max-limit=20M priority=2 packet-mark=sip The bucket levels would all be default, so 0.1 What I can't get my head around is what values I would use for the buckets, I don't want busting to happen I just want guaranteed capacity for the voice packets at all times and the other queue to be backed off if need be, so based on the doco it seems that I should set the bucket size on the voice queue higher so it borrows more tokens from the parent then the other queue can, am I on the right track with that ? Regards Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Philip Loenneker Sent: Friday, 14 December 2018 6:15 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] QOS Hi all, The presentation Jason mentioned was by TasmaNet, with me presenting :) MikroTik recorded it and you can view it here: https://youtu.be/DipIAJyOxJM It's about 49mins long. Feel free to ask me any questions you have about it. Regards, Philip Loenneker | Network Engineer | TasmaNet 40-50 Innovation Drive, Dowsing Point, Tas 7010, Australia P: 1300 792 711 philip.loenneker@tasmanet.com.au www.tasmanet.com.au -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Paul Julian Sent: Friday, 14 December 2018 5:01 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] QOS Hmm, interesting, OK I will dig that out. Thanks Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Jason Hecker (Up & Running Tech) Sent: Friday, 14 December 2018 4:59 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] QOS Have a look at the Tasmanian ISP talk from the May MUM. They mentioned something about needing to adjust the token bucket sizes as well to keep the bitrate tolerances within NBN requirements. You have a few knobs to play with to improve your QOS. Good luck... I think experimentation on the way to understanding is the only way to go. On Fri, 14 Dec 2018 at 16:42, Paul Julian <paul@buildingconnect.com.au> wrote:
Hi all, how many people actually implement a QOS design within an ISP network which is for data heading from a DSLAM or router TO the customer ?
I am interested to know of those that do are you dynamically managing the QOS using prioritisation of packets or are you hard setting speeds in multiple queues to manage the VOIP quality heading to the customer ? We have written a system which dynamically prioritises packets to the customer, it tears down the default queue created at PPPOE login time and then builds a new queue structure with a parent and two children, one for VOIP and one for everything else.
It works very well, however the Mikrotik priority system is a little slow in reacting sometimes for VOIP and we still see some packets not getting through in front of a large download which is smashing the connection for example.
We can obviously reduce traffic bandwidth in the non-VOIP queue but that would be a permanent thing so even when there was no VOIP traffic they still wouldn't see maximum bandwidth.
We know how to handle both scenarios but I am just interested in how others handle it or whether they do it at all....
Regards Paul _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
-- <https://www.upandrunningtech.com.au> _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au