QOL recommendations for QoS and NAT for DumaOS

[robcore]

Please look into

QoS:

- Device Independant Type of Service prioritization, capable of re-ordering various common ports/traffic types as needed.  Allowing a "custom port" option would go a long way as well.

- More common protocol types in the prioritization fields than just tcp and udp, as sctp has become a common protocol for gaming, for example.  As well, "all" or "0" would be a useful option for full device prioritization.

NAT/Port Forwarding:

- Real full cone support (I can link the patches if it helps) or a dedicated console dmz would be very helpful.

- Again, more protocols supported for forwarding.

 

Thanks and have a good one!

Edit: For QoS, device prioritization as a separate option from bandwidth slice would be good too, as often the services whose packets we need to go out first don't necessarily require high bandwidth.

Also, offline devices NEED to be removed from QoS calculation AUTOMATICALLY.  Frankly, I was surprised to see that I needed to remove an offline device from dhcp reservation and manually update the distribution table when a device leaves the network.  You guys need to base distribution solely on connection status because I don't want to have to manually update router settings every time I turn off a computer.

Edited January 14, 2019 by robcore

[bbursley]

On 1/13/2019 at 9:23 PM, robcore said:

Please look into

QoS:

- Device Independant Type of Service prioritization, capable of re-ordering various common ports/traffic types as needed.  Allowing a "custom port" option would go a long way as well.

- More common protocol types in the prioritization fields than just tcp and udp, as sctp has become a common protocol for gaming, for example.  As well, "all" or "0" would be a useful option for full device prioritization.

NAT/Port Forwarding:

- Real full cone support (I can link the patches if it helps) or a dedicated console dmz would be very helpful.

- Again, more protocols supported for forwarding.

 

Thanks and have a good one!

Edit: For QoS, device prioritization as a separate option from bandwidth slice would be good too, as often the services whose packets we need to go out first don't necessarily require high bandwidth.

Also, offline devices NEED to be removed from QoS calculation AUTOMATICALLY.  Frankly, I was surprised to see that I needed to remove an offline device from dhcp reservation and manually update the distribution table when a device leaves the network.  You guys need to base distribution solely on connection status because I don't want to have to manually update router settings every time I turn off a computer.

With share excess this really doesn’t matter aside from having to see it under the flower really. Whatever bandwidth the devices aren’t using just get shared among the others if they call for it. 

[Netduma Fraser]

Hi Rob, I've passed you suggestions onto the team!

[robcore]

14 hours ago, bbursley said:

With share excess this really doesn’t matter aside from having to see it under the flower really. Whatever bandwidth the devices aren’t using just get shared among the others if they call for it. 

I see where your coming from, but it's still wasted computational power and milliseconds of calculation for something that isn't there.  Offline devices shouldn't factor in to qos whatsoever.

I have an R1 and am XR500, and they are the best on the market in this area, but that doesn't mean that they can't be improved.  I don't like to settle when it comes to programming, and I imagine the Duma team doesn't either.

[Netduma Jack]

15 hours ago, robcore said:

I see where your coming from, but it's still wasted computational power and milliseconds of calculation for something that isn't there.  Offline devices shouldn't factor in to qos whatsoever.

I have an R1 and am XR500, and they are the best on the market in this area, but that doesn't mean that they can't be improved.  I don't like to settle when it comes to programming, and I imagine the Duma team doesn't either.

Great suggestions, thanks for these. We'll never settle, since improvements can always be made. We're actually working on ways to deal with offline devices better, since we aren't too happy with how the current Device Manager handles it. All sorts of exciting stuff coming this year