Google Hangout – Performance through Proxies

For my current client we’ve had a request in to enable video Hangouts. The first attempt was to run the traffic through the on-premise McAfee Web Gateways that are used to inspect all traffic in and out of the Internet. Performance wasn’t great and on looking closer we could see that all traffic was TCP based. In consultation with the supplier the conclusion was that the MWG can only process TCP traffic as it’s a stateful engine. We knew we needed to be using UDP to get the performance we needed as this was a video stream.

We reconfigured a single office to route the Google netblock of addresses directly to the perimeter firewalls and then conducted an experiment to see what happened. The pilot user population reported great performance. This was a bit of a surprise as we had expected to do DNS changes to allow the Chrome Hangout functionality (which was previously a discrete plug-in) to resolve the video servers. By default all our browser clients hand off all Internet access to the MWG’s including DNS resolution.

In consultation with some Google deployment specialists we believe that the following is happening:

1. Both users start their Chrome browser which immediately establishes a TCP connection to Google through the MWG’s
2. One user calls the other using Hangouts, the session initiation is established over the existing TCP connection to Google
3. Each client initiates UDP traffic to Google using the subset of Google netblock IP addresses returned in the session initiation
4. Video commences

The key points to note are that the Hangouts video functionality didn’t need to resolve the IP address hence we didn’t have to expose Internet name resolution into the internal DNS. The Hangouts functionality is not proxy aware – the UDP traffic was routed by default, enabled by the office router change directing Google traffic to the perimeter firewalls. My belief is that the Hangouts functionality tries to route out to Google before falling back to other protocols (and potentially discovering the MWG’s).

There is discussion out on the Internet about full cone NAT firewalls and the like. Our perimeter firewalls (without divulging suppliers) do NATing and are smart enough to allow inbound UDP traffic to be received and routed to the client that sent out UDP traffic to Google even though the traffic from Google is essentially unsolicited. I guess that makes them full cone.


About Matt Sinfield

Work in the IT industry but have a couple of hobbies, Snowboard, Kitesurf and of course XBox
This entry was posted in Work and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s