> and cutting deals with carriers directly to adjust the timeouts for their IP ranges specifically In theory, seems like they could just sidestep the NAT entir

> and cutting deals with carriers directly to adjust the timeouts for their IP ranges specifically In theory, seems like they could just sidestep the NAT entirely. Co-locate a front-end server inside the carrier's private network. Then the phone and front-end server talk to each other with private addresses. Once it hits the front-end server, everything can be multiplexed over a single TCP connection back to the Google data center. (You'd need a way to discover the server, but that's doable. For example, the regular server can refer you based on cell carrier, source IP, etc.) Google already has reasons to want servers co-located, such as serving static web content and making sure new TCP connections warm up fast. Apple too, somewhat. So the hardware might be there already and this might be just a configuration change, possibly including the addition of a private address. Point being, the economies of scale here might be even greater. They might have a nearly free way to do it, and without the need to convince the carrier to give up precious NAT resources.