The ZyXEL VMG1312 has QoS enabled by default with a set of default rules giving priorities to various protocols.
Initial findings show that the default settings may not ideal.
The examples below are when using the VMG1312 in router mode on a FTTC line. The VMG1312 is plugged directly in to the phone line (via a SSFP), and providing a firewalled, no-nat and DHCP connection to the LAN.
The QoS settings on the VMG1312 will control the upload traffic. Download is already handled at the AAISP side where we give priority to small packets as well as the option to rate-limit the line slightly to improve performance.
The effect of disabling QoS
Here we are running a backup job, an rsync (over ssh). Just after 7am QoS is disabled for around 30 minutes. The latency (blue) immediately jumps up to an average of 350ms. It was less than 20ms with QoS enabled.
Problems with default settings
With the default settings, running an rsync over ssh backup, kills DNS lookups completely! SSH has a higher priority than DNS, and with all the SSH traffic DNS lookups can't get a word in edgeways.
AA Default VMG1312 Settings
We set the QoS be simply based on packet size. We deactivate the various default Classes and Queues and rely on the setting to let small packets jump the queue. This typically gives VoIP, DNS and other 'real time' protocols priority. This is similar to the way that the core routers at the AAISP side work.
QoS on our CQM Monitoring
With QoS enabled simply based on packet size internet activity is unaffected but a large upload happening at the same time. The example above shows a 40/10 FTTC line with a 10Mbit/s rsync backup upload happening. With QoS disabled there is terrible latency (blue), a small about of packet loss (red at the top) and generally, the internet access is affected quite a lot. With QoS based on packet size enabled, VoIP traffic is unaffected and general internet access such as streaming carries on as normal. The ZyXEL is able to manage the upload as it knows what the speed of the line is and gives priority to small packets which tend to be protocols that require near real-time responses.
We welcome any customer feedback as to these QoS settings. We're happy for customers to modify their config if they would like, but these settings would get overwritten if a config is ever sent from the AAISP side to the router.