2. Optimize your network for Meet

To set up your network for the best possible Meet video meetings:

  1. Make sure the site has enough bandwidth for the maximum number of participants meeting concurrently. See Network connectivity requirements for Meet.
  2. Configure the network for low latency between the participant devices and Google. To achieve this:
    1. Create a Cloud-friendly network.
    2. Do not use proxies, QoS, or packet inspection or protocol analyzers.
      These features can impact Meet video and audio quality. They introduce or alter latency and jitter, which is used to estimate network congestion and available bandwidth. 

If proxies, QoS, or packet inspection/protocol analyzers must be used, see the following information to properly implement these features.

How Meet adapts to network constraints 

Meet automatically adapts to the available bandwidth by detecting network congestion using the GCC (Google Congestion Control) algorithm. 

If media packets stop arriving as frequently as they were before, then the packets were buffered in a network node that does not have enough capacity to send them forward. Meet uses this information to determine that the network is congested and adapt the media stream bitrates.

Create a Cloud-friendly network 

A Cloud-friendly network infrastructure allows Meet traffic to efficiently communicate with the Google infrastructure. To create this:

  1. Make sure Meet traffic has a short path to the internet. Avoid: 
    • Proxies
    • Packet inspection or protocol analyzers
  2. Measure and optimize your:
Proxy best practices

Do not use proxy servers for Meet traffic

We strongly recommend that your network not use proxy servers for Meet traffic. To do this, whitelist Meet traffic in the proxy configuration. 

Proxying traffic adds latency and may cause Meet to automatically reduce the video and audio quality. Meet performance is optimal when the latency between the client and Google back end is lower than 100 ms. In addition, Meet provides all the benefits for video traffic that a proxy does, so a proxy is not needed.  

If proxy servers must be used

We strongly advise against the use of a proxy. But if you have a clear use case that absolutely requires it, understand that proxy servers can severely impact performance. If proxies are used in your network, note the following:

Packet inspection/protocol analyzers

If at all possible, do not use packet inspection or protocol analyzers for Meet, because they introduce latency that may cause the Meet infrastructure to automatically reduce video meeting quality. The additional latency often severely impacts real time traffic such as video conference. This additional latency is often high enough to prevent video meetings from functioning.

Packet inspection of video traffic also yields little benefit, because automated scanning tools can’t reconstruct media stream data.

If these tools are used, whitelist all Meet traffic port numbers to bypass them. 

Wi-Fi best practices

The following recommendations apply to typical office environments. A wireless engineer should evaluate on a case-by-case basis more complex environments, such as manufacturing floors, areas with high levels of RF noise, or sparsely covered spaces. 

Running real-time applications over a wireless network can be challenging. This is because the underlying radio frequency (RF) spectrum and bandwidth is shared among all the devices using it. 

Carefully review the following considerations during the design, deployment, and operation of wireless networks used with Meet.

2.4GHz vs 5GHz RF bands

We generally recommend that real-time applications not be deployed and operated over the (typically heavily used) 2.4GHz band of a wireless network. This includes those that provide connectivity in an ordinary office environment.

The 2.4Ghz band is problematic because it has only 3 non-overlapping channels, typically high noise levels from nearby interfering networks, and extra interference from other devices (microwaves, for example), creating a noisy and complex  radiofrequency (RF)  environment. 

Reliable operation of real-time applications like Meet rely on adequate capacity, delay, jitter and packet-loss levels. These are almost impossible to achieve over the 2.4 GHz band. 

Design/deployment considerations

If you design a wireless network that will support real-time applications, think about capacity rather than coverage.

  • Manage cell size, which is controlled by the transmit power of the access point (AP). Deploy smaller cells where more devices are expected, such as meeting rooms and auditoriums to increase capacity. Bigger cells can provide general coverage on the office floor.
  • Disable low rates to improve RF usage efficiency. This forces a client’s handover to the closest AP while roaming between APs.

If a wireless network’s SSID is available on both bands (2.4GHz and 5GHz), the network should implement aggressive band steering to force clients onto the 5GHz band.

To allow advanced features, such as seamless roaming between APs and proper RF management, a wireless network should be centrally managed and operated—not a collection of siloed, standalone APs. 

Finally, perform a post-deployment wireless survey to confirm wireless coverage throughout the spaces where Meet is typically used.

WMM best practices

To support reliable Meet communication over wireless networks, implement Wireless Multimedia Extensions (WMM). 

Meet traffic needs to be classified by the wireless controller/AP based either on the Meet-specific protocols and ports or, if sufficient trust is present in the network, by the DSCP field value set by other network equipment. 

While full WMM support (including clients) is required to provide bidirectional QoS, you can also configure it at the network level (on the controller/AP) to provide significant benefits. Meet traffic should be assigned to either the audio or video queue on the wireless AP/controller and receive preferential treatment over other classes of traffic.

Restrict outbound traffic to Google IPs (netblocks)

Meet traffic is secured and encrypted, so there is no need to restrict traffic to the G Suite IPs. 

If, however, you have network constraints that require you to restrict traffic, then use the following set of IP ranges (netblocks) to make sure all outbound Meet traffic goes to Google. G Suite services all share the same IP netblocks.

Google maintains a global infrastructure, which grows dynamically to accommodate increasing demand. As a result, G Suite servers use a large range of IP addresses, and the addresses often change. The most effective means of finding the current range of Google IP addresses is to query Google's SPF record.

Use nslookup to discover and list these IP ranges:

  • nslookup -q=TXT _netblocks.google.com
  • nslookup -q=TXT _netblocks2.google.com
  • nslookup -q=TXT _netblocks3.google.com

Currently, G Suite and Google Compute Engine (GCE) IP netblocks do not overlap. For details, see the GCP FAQ.  

QoS best practices

Do not use QoS

You should not use QoS for Meet in your network, because Meet automatically adapts to network conditions. Use QoS only if you have compelling reasons, such as a congested network, and are able to deploy and maintain an end-to-end QoS model in your network.  

If QoS must be used

If your network is congested and you must secure a certain quality of service (QoS) for Meet, employ the best practices described in the following document.

Limit Meet traffic
You have 2 options for limiting Meet traffic: 
  • If your enterprise has limited bandwidth, use QoS to reserve or limit traffic for Meet. See QoS best practices above for more information.
  • To restrict traffic only on certain devices, limit the bandwidth at the client level. Set an Outbound Throttle Rate through a Windows QoS Policy in the Group Policy Management Console and identify Meet traffic with Meet’s port range.



Was this article helpful?
How can we improve it?