Meet QoS best practices

You shouldn’t use quality of service (QoS) for Google Meet in your network because Meet automatically adapts to network conditions. Use QoS only if you have a compelling reason, such as a congested network, and are able to deploy and maintain an end-to-end QoS model in your network.

If you must use QoS

If your network is congested and you must secure a certain QoS for Meet, choose one of the following options:

• Add QoS on Meet clients.
• Add QoS at the network edge.

Option 1: Add QoS on Meet clients

If you add QoS on Meet clients, Meet traffic is tagged on the client machines for QoS within the enterprise network. The QoS tags are removed when the traffic is sent to the internet. Incoming Meet traffic is tagged when it enters the enterprise network.

To add QoS on Meet clients:

1. Set a DSCP marking through a Windows QoS policy in the Group Policy Management Console.
2. Identify Meet traffic using Meet’s port range as described in Prepare your network for Meet Meetings.
3. Remove the DSCP tagging for the traffic that leaves your internal gateway to the internet.
4. Tag Meet traffic received from the internet. This internet traffic is the real-time transport protocol or real-time transport control protocol (RTP/RTCP) traffic that uses the Meet port ranges.

Option 2: Add QoS at the network edge

With this option, client Meet traffic is tagged at the network edge for QoS within the enterprise network. The QoS tags are removed when the traffic is sent to the internet. Incoming Meet traffic is tagged when it enters the enterprise network.

To add QoS at the network edge:

1. On all network edges, add a rule to mark Meet traffic. You should assign the Expedited Forward (EF) class for Meet traffic to ensure low delay and low jitter. This traffic is the RTP/RTCP traffic that uses the Meet port ranges.
2. Remove the DSCP tagging for the traffic that leaves your internal gateway to the internet.
3. Tag Meet traffic received from the internet using the EF class. This traffic is the RTP/RTCP traffic that uses the Meet port ranges.
4. Within your company, to achieve low delay, jitter, and loss values, prioritize EF traffic and place it into low latency or strict priority queues. Implement additional precautions, such as rate limiting above predefined bandwidth values, to make sure that EF traffic doesn’t limit other traffic classes on the network.

Test QoS

Different hardware vendors have different QoS implementations so testing can differ slightly. Fine-tune to ensure end-to-end QoS. 

1. Start with a small test environment to review how a single device performs.
2. Follow the packets’ path through the individual network devices to validate that the network path respects client markings and understand individual queue drops and throughput on devices. 
3. Review the sections below on this page to further review and test QoS.

Some non-intelligent network devices, such as a hub or low-end switch, might not support the full QoS feature. Make sure that the DSCP value marked at the upstream device is not modified. This way, the downstream intelligent devices can apply the correct QoS strategy based on the correct marking.

Ensuring the network path respects client markings

You can verify correct DSCP markings using the following tools:

• Packet sniffing—Use packet sniffing with Wireshark, for example, to help you verify the correct DSCP markings on both the network device (AP, router, or switch) and end device (computer). Use port mirroring or switch port analyzer (SPAN) to send captured data to a selected destination port for local port mirroring. A remote port protocol, such as remote switch port analyzer (RSPAN), can send captured data to a remote server for analysis.
• NetFlow—You can use NetFlow to verify the DSCP marking on the network device. The DSCP value is exported by default to the collector. Filter the 5-tuple (IP, protocols, and ports) from the captured data to verify the DSCP value for each specific application.

Monitor Meet QoS performance on the network level

Use a Simple Network Management Protocol (SNMP)-based monitoring tool to display the trending view of different queue utilizations and queue drop rates. If you mark Meet at the application level as EF, you can look at EF utilization and the drop rate of this class to understand the Meet performance for an interface on the network.

By aggregating the application data, NetFlow can display a stacking view of a site-specific or global view.

Simulate congestion & QoS validation

1. Generate multiple flows of traffic in your test environment that exceed the maximum bandwidth of the media. For example, generate 2 Gbps traffic over a 1 Gbps path. 
2. Compare the throughput at the receiving endpoint to verify if high-priority traffic gets adequate treatment.

To simulate congestion on wireless networks:

1. Generate multiple flows to the same access point. For example, for 802.11n, send 2 by 150 mbps for each flow because 802.11n can support a maximum throughput of approximately 180 mbps.
2. Verify the throughput at the receiving endpoint.

For example, to prove high-priority traffic gets better service, send a different class of traffic over Wi-Fi (at the same access point, in the same collision domain). High-priority traffic should get all the throughput without dropping, while low-priority traffic should drop dramatically.

To test that QoS is performing as expected, enter the following commands:

• For best effort, enter iperf3 -c IP address -u -b 150m -t 50 -l 1000B -i 10 -S 0x0.
• For EF, enter iperf3 -c IP address -u -b 150m -t 50 -l 1000B -i 10 -S 0xB8.