Community discussions

MikroTik App
 
syadnom
Forum Veteran
Forum Veteran
Topic Author
Posts: 794
Joined: Thu Jan 27, 2011 7:29 am

How to offer to pay for a new feature?

Tue Sep 18, 2018 3:36 am

Calling admins! I have a feature that I'm really really needing and willing to pay for development on. How can I talk with someone at Mikrotik to see if it's something you guys are willing to do?
 
jarda
Forum Guru
Forum Guru
Posts: 7756
Joined: Mon Oct 22, 2012 4:46 pm

Re: How to offer to pay for a new feature?

Tue Sep 18, 2018 1:39 pm

You can rise the feature request here. May happen everyone would like it too like you and mikrotik will hear all and one day after few years you can get it in beta.
 
User avatar
baragoon
Member Candidate
Member Candidate
Posts: 294
Joined: Thu Jan 05, 2017 10:38 am
Location: Kyiv, UA
Contact:

Re: How to offer to pay for a new feature?

Tue Sep 18, 2018 1:47 pm

You can rise the feature request here. May happen everyone would like it too like you and mikrotik will hear all and one day after few years you can get it in beta.
maybe :)
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3279
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: How to offer to pay for a new feature?

Tue Sep 18, 2018 2:09 pm

What is the feature you need?
 
syadnom
Forum Veteran
Forum Veteran
Topic Author
Posts: 794
Joined: Thu Jan 27, 2011 7:29 am

Re: How to offer to pay for a new feature?

Tue Sep 18, 2018 5:28 pm

I need a new tunnel type. Could be a modified tunnel. Need 2 features in one. Forward error correction and backup tunnel.

a) FEC added to the tunnel using reed-solomon or Raptorq. Essentially if there is some packet loss within the configured thresholds the packet will get rebuilt. tinyfecvpn can be used as a fantastic example. You can configure an amount of redundancy to calculate and a wait period. The FEC adds sequence numbers and if a packet is missing or even too slow for that wait period, it just gets rebuild. This solves packet loss and jitter in one.

b) a 'backup tunnel' option in the tunnel config and a BFD like detector with configurable latency. Second tunnel could be a truly secondary tunnel that you just select from a list, or inbuilt with an interface selector like so:
tun1-interface=ether1
tun2-interface=ether2
tun1-src-address=<optional>
tun2-src-address=<optional>
tun1-dst-address=1.1.1.1
tun2.dst-address=2.2.2.2

<optionals> because if you are behind NAT, that needs to be discovered via src-address on the remote side. IPIP does this now no problem. Source interface is REQUIRED because we can't always know the src address until an interface gets one and I want this to be super simple to setup, not requiring a bunch of scripts.

the purpose being to have reaction times as low as you dare configure them. We only need to monitor the first link. Need a BFD like monitor that sends heartbeats at a configurable interval with sequence numbers. Link is considered failed if it's fails to receive a configurable sequence* of packets and link isn't up until it's received a configurable number of packets in sequence (*have some tollerance for jitter, but not much). When that link is considered down, packets are redirected to tun2 until tun1 gets n packets in sequence. With voip and fec, we can't wait for a negotiation between two sides so we just have to assume that if we can't receive all the packets, we probably can't send them cleanly either. And we can't push latency out too far either and the FEC code is going to add a little so we really need to switch to tun2 before the FEC depth is hit. The second link needs only a 5 second ping or so just to see that the interface is up. If it's down, we can't hop over and just have to cope.

This is all to make a very resilient tunnel between mikrotik endpoints that can absorb packet loss, jitter, and provide redundancy.
 
syadnom
Forum Veteran
Forum Veteran
Topic Author
Posts: 794
Joined: Thu Jan 27, 2011 7:29 am

Re: How to offer to pay for a new feature?

Tue Sep 18, 2018 5:31 pm

also, I'm already doing the redundancy with dual tunnels and OSPF. But even with BFD the reaction time to switch tunnels is over 1 second AND requires a relatively complex setup AND OSPF on the second link eats LTE data.

Can't use a bond because that's ethernet based and I need non-ethernet tunnels here. IPIP for example.
 
r00t
Long time Member
Long time Member
Posts: 672
Joined: Tue Nov 28, 2017 2:14 am

Re: How to offer to pay for a new feature?

Wed Sep 19, 2018 3:48 am

FEC tunel is really awesome, I have played with tinyfecvpn and it can make bad connection usable for VOIP and other realtime services. You trade in bandwidth for better and smoother latency and no packet loss.
Sadly there are many similar features that would be nice to have (just look into "Feature requests" thread, it's probably the longest thread on this forum). Seems like Mikrotik doesn't have enough developers... and they are all mostly busy slowly fixing all the bugs.
But if you really need these features and have enough money to spend, you can try your luck by contacting support with your proposal... it's worth a try.
Posting on this forum usually doesn't change anything...

Who is online

Users browsing this forum: oliverlexis, Renfrew and 60 guests