Hi Jason, We use PFIFO and depending on the connection speed we adjust the queue size. For example around 25-50Mbit/s we run a 200 packet queue, obviously for VOIP we don't queue but it still uses PFIFO We have found with testing that PFIFO seems to work the best, but happy to be convinced otherwise ૘ෞ਀ഀ਀刀攀最愀爀搀猀ഀ਀倀愀甀氀ഀ਀ഀ਀ⴀⴀⴀⴀⴀ伀爀椀最椀渀愀氀 䴀攀猀猀愀最攀ⴀⴀⴀⴀⴀഀ਀䘀爀漀洀㨀 倀甀戀氀椀挀 㰀瀀甀戀氀椀挀ⴀ戀漀甀渀挀攀猀䀀琀愀氀欀⸀洀椀欀爀漀琀椀欀⸀挀漀洀⸀愀甀㸀 伀渀 䈀攀栀愀氀昀 伀昀 䨀愀猀漀渀 䠀攀挀欀攀爀 ⠀唀瀀 ☀ 刀甀渀渀椀渀最 吀攀挀栀⤀ഀ਀匀攀渀琀㨀 䘀爀椀搀愀礀Ⰰ ㄀㐀 䐀攀挀攀洀戀攀爀 ㈀　㄀㠀 㐀㨀㔀㔀 倀䴀ഀ਀吀漀㨀 䴀椀欀爀漀吀椀欀 䄀甀猀琀爀愀氀椀愀 倀甀戀氀椀挀 䰀椀猀琀 㰀瀀甀戀氀椀挀䀀琀愀氀欀⸀洀椀欀爀漀琀椀欀⸀挀漀洀⸀愀甀㸀ഀ਀匀甀戀樀攀挀琀㨀 刀攀㨀 嬀䴀吀ⴀ䄀唀 倀甀戀氀椀挀崀 儀伀匀ഀ਀ഀ਀圀栀椀挀栀 欀椀渀搀 漀昀 焀甀攀甀攀猀 愀爀攀 礀漀甀 甀猀椀渀最㼀  倀䌀儀㼀 䘀䤀䘀伀㼀  圀栀愀琀 愀爀攀 琀栀攀 戀甀昀昀攀爀 猀椀稀攀猀 漀昀 礀漀甀爀 焀甀攀甀攀猀㼀  夀漀甀✀氀氀 栀愀瘀攀 琀漀 愀搀樀甀猀琀 琀栀攀洀 昀爀漀洀 琀栀攀 搀攀昀愀甀氀琀 瘀愀氀甀攀 琀漀 猀甀椀琀 礀漀甀爀 氀椀渀攀 猀瀀攀攀搀 ⠀礀攀 漀氀搀攀 戀甀昀昀攀爀 戀氀漀愀琀⤀⸀ഀ਀ഀ਀伀渀 䘀爀椀Ⰰ ㄀㐀 䐀攀挀 ㈀　㄀㠀 愀琀 ㄀㘀㨀㐀㈀Ⰰ 倀愀甀氀 䨀甀氀椀愀渀 㰀瀀愀甀氀䀀戀甀椀氀搀椀渀最挀漀渀渀攀挀琀⸀挀漀洀⸀愀甀㸀ഀ਀眀爀漀琀攀㨀ഀ਀ഀ਀㸀 䠀椀 愀氀氀Ⰰ 栀漀眀 洀愀渀礀 瀀攀漀瀀氀攀 愀挀琀甀愀氀氀礀 椀洀瀀氀攀洀攀渀琀 愀 儀伀匀 搀攀猀椀最渀 眀椀琀栀椀渀 愀渀 䤀匀倀 ഀ਀㸀 渀攀琀眀漀爀欀 眀栀椀挀栀 椀猀 昀漀爀 搀愀琀愀 栀攀愀搀椀渀最 昀爀漀洀 愀 䐀匀䰀䄀䴀 漀爀 爀漀甀琀攀爀 吀伀 琀栀攀 挀甀猀琀漀洀攀爀 㼀ഀ਀㸀ഀ਀㸀 䤀 愀洀 椀渀琀攀爀攀猀琀攀搀 琀漀 欀渀漀眀 漀昀 琀栀漀猀攀 琀栀愀琀 搀漀 愀爀攀 礀漀甀 搀礀渀愀洀椀挀愀氀氀礀 洀愀渀愀最椀渀最 ഀ਀㸀 琀栀攀 儀伀匀 甀猀椀渀最 瀀爀椀漀爀椀琀椀猀愀琀椀漀渀 漀昀 瀀愀挀欀攀琀猀 漀爀 愀爀攀 礀漀甀 栀愀爀搀 猀攀琀琀椀渀最 猀瀀攀攀搀猀 ഀ਀㸀 椀渀 洀甀氀琀椀瀀氀攀 焀甀攀甀攀猀 琀漀 洀愀渀愀最攀 琀栀攀 嘀伀䤀倀 焀甀愀氀椀琀礀 栀攀愀搀椀渀最 琀漀 琀栀攀 挀甀猀琀漀洀攀爀 㼀ഀ਀㸀 圀攀 栀愀瘀攀 眀爀椀琀琀攀渀 愀 猀礀猀琀攀洀 眀栀椀挀栀 搀礀渀愀洀椀挀愀氀氀礀 瀀爀椀漀爀椀琀椀猀攀猀 瀀愀挀欀攀琀猀 琀漀 琀栀攀 ഀ਀㸀 挀甀猀琀漀洀攀爀Ⰰ 椀琀 琀攀愀爀猀 搀漀眀渀 琀栀攀 搀攀昀愀甀氀琀 焀甀攀甀攀 挀爀攀愀琀攀搀 愀琀 倀倀倀伀䔀 氀漀最椀渀 琀椀洀攀 ഀ਀㸀 愀渀搀 琀栀攀渀 戀甀椀氀搀猀 愀 渀攀眀 焀甀攀甀攀 猀琀爀甀挀琀甀爀攀 眀椀琀栀 愀 瀀愀爀攀渀琀 愀渀搀 琀眀漀 挀栀椀氀搀爀攀渀Ⰰ ഀ਀㸀 漀渀攀 昀漀爀 嘀伀䤀倀 愀渀搀 漀渀攀 昀漀爀 攀瘀攀爀礀琀栀椀渀最 攀氀猀攀⸀ഀ਀㸀ഀ਀㸀 䤀琀 眀漀爀欀猀 瘀攀爀礀 眀攀氀氀Ⰰ 栀漀眀攀瘀攀爀 琀栀攀 䴀椀欀爀漀琀椀欀 瀀爀椀漀爀椀琀礀 猀礀猀琀攀洀 椀猀 愀 氀椀琀琀氀攀 ഀ਀㸀 猀氀漀眀 椀渀 爀攀愀挀琀椀渀最 猀漀洀攀琀椀洀攀猀 昀漀爀 嘀伀䤀倀 愀渀搀 眀攀 猀琀椀氀氀 猀攀攀 猀漀洀攀 瀀愀挀欀攀琀猀 渀漀琀 ഀ਀㸀 最攀琀琀椀渀最 琀栀爀漀甀最栀 椀渀 昀爀漀渀琀 漀昀 愀 氀愀爀最攀 搀漀眀渀氀漀愀搀 眀栀椀挀栀 椀猀 猀洀愀猀栀椀渀最 琀栀攀 ഀ਀㸀 挀漀渀渀攀挀琀椀漀渀 昀漀爀 攀砀愀洀瀀氀攀⸀ഀ਀㸀ഀ਀㸀 圀攀 挀愀渀 漀戀瘀椀漀甀猀氀礀 爀攀搀甀挀攀 琀爀愀昀昀椀挀 戀愀渀搀眀椀搀琀栀 椀渀 琀栀攀 渀漀渀ⴀ嘀伀䤀倀 焀甀攀甀攀 戀甀琀 ഀ਀㸀 琀栀愀琀 眀漀甀氀搀 戀攀 愀 瀀攀爀洀愀渀攀渀琀 琀栀椀渀最 猀漀 攀瘀攀渀 眀栀攀渀 琀栀攀爀攀 眀愀猀 渀漀 嘀伀䤀倀 琀爀愀昀昀椀挀 ഀ਀㸀 琀栀攀礀 猀琀椀氀氀 眀漀甀氀搀渀✀琀 猀攀攀 洀愀砀椀洀甀洀 戀愀渀搀眀椀搀琀栀⸀ഀ਀㸀ഀ਀㸀 圀攀 欀渀漀眀 栀漀眀 琀漀 栀愀渀搀氀攀 戀漀琀栀 猀挀攀渀愀爀椀漀猀 戀甀琀 䤀 愀洀 樀甀猀琀 椀渀琀攀爀攀猀琀攀搀 椀渀 栀漀眀 ഀ਀㸀 漀琀栀攀爀猀 栀愀渀搀氀攀 椀琀 漀爀 眀栀攀琀栀攀爀 琀栀攀礀 搀漀 椀琀 愀琀 愀氀氀⸀⸀⸀⸀ഀ਀㸀ഀ਀㸀 刀攀最愀爀搀猀ഀ਀㸀 倀愀甀氀ഀ਀㸀 开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开ഀ਀㸀 倀甀戀氀椀挀 洀愀椀氀椀渀最 氀椀猀琀ഀ਀㸀 倀甀戀氀椀挀䀀琀愀氀欀⸀洀椀欀爀漀琀椀欀⸀挀漀洀⸀愀甀ഀ਀㸀 栀琀琀瀀㨀⼀⼀琀愀氀欀⸀洀椀欀爀漀琀椀欀⸀挀漀洀⸀愀甀⼀洀愀椀氀洀愀渀⼀氀椀猀琀椀渀昀漀⼀瀀甀戀氀椀挀开琀愀氀欀⸀洀椀欀爀漀琀椀欀⸀挀漀洀⸀ഀ਀㸀 愀甀ഀ਀㸀ഀ਀ഀ਀ഀ਀ⴀⴀഀ਀㰀栀琀琀瀀猀㨀⼀⼀眀眀眀⸀甀瀀愀渀搀爀甀渀渀椀渀最琀攀挀栀⸀挀漀洀⸀愀甀㸀ഀ਀开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开ഀ਀倀甀戀氀椀挀 洀愀椀氀椀渀最 氀椀猀琀ഀ਀倀甀戀氀椀挀䀀琀愀氀欀⸀洀椀欀爀漀琀椀欀⸀挀漀洀⸀愀甀ഀ਀栀琀琀瀀㨀⼀⼀琀愀氀欀⸀洀椀欀爀漀琀椀欀⸀挀漀洀⸀愀甀⼀洀愀椀氀洀愀渀⼀氀椀猀琀椀渀昀漀⼀瀀甀戀氀椀挀开琀愀氀欀⸀洀椀欀爀漀琀椀欀⸀挀漀洀⸀愀甀ഀ਀

How'd you go with BFIFO instead? Until FQ-CODEL comes along I figure there might be something similar possible by scaling Limit and Total Limit in a PCQ to keep them as short as possible for the channel bitrate. On Fri, 14 Dec 2018 at 16:59, Paul Julian <paul@buildingconnect.com.au> wrote:

Hi Jason,

We use PFIFO and depending on the connection speed we adjust the queue size. For example around 25-50Mbit/s we run a 200 packet queue, obviously for VOIP we don't queue but it still uses PFIFO

We have found with testing that PFIFO seems to work the best, but happy to be convinced otherwise Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

-- <https://www.upandrunningtech.com.au>

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

LOL, I am watching that right now !! Thanks 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

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

Hi Philip. Yes that was my concern about these changes, I was not really sure it would help as it seems to be mostly around bursting and not around committed rates. I have been thinking along the same lines as your suggestion. For example on a 20M link I was thinking of setting the limit-at and max-limit at 20M for the parent queue, then say limit-at=2M and max-limit=20M for voice, then say limit-at=18M and max-limit=20M for other queue. That would be how I would normally break something up based on CIR and MIR/PIR where the sum of the limit-at values should equal the max-limit values. Plus probably adding in the priorities as well can't hurt, but I don't think I will gain any benefit in this scenario from the bucket size option. I am happy to be proven wrong though, always willing to learn something new ! Regards Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Philip Loenneker Sent: Monday, 17 December 2018 1:46 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] QOS 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 _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au