Why do mobile networks have high latencies? How can they be reduced?
Solution 1:
The book "High Performance Browser Networking" from Ilya Grigorik answers exactly this. There is a whole chapter (7th) dedicated to mobile networks. The book states that the problem with high performance is almost always tied to latency, we usually have plenty of bandwidth but the protocols gets in the way. Be it TCP slow start, the Radio Resource Controller (RRC) or suboptimal configurations. If you are experiencing poor latency only in mobile networks it's the way they are designed.
There is a table in the book about typical latencies:
Table 7-2. Data rates and latency for an active mobile connection
Generation | Data rate | Latency 2G | 100–400 Kbit/s | 300–1000 ms 3G | 0.5–5 Mbit/s | 100–500 ms 4G | 1–50 Mbit/s | < 100 ms
Although very relevant to latency the TCP characteristic three-way handshake or the slow-start don't really answer the question, as they affect wired connections equally. What does really affect the latency in mobile networks is the layer under IP. If the layer under IP has a latency of half a second, a TCP connection to a server will take ~1.5 sec (0.5s*3), as you see the numbers add up pretty quick. As said before that's supposing that the mobile is not idle. If the handset is idle it first has to "connect" to the network, that requires to negotiate a reserve of resources with the tower (simplified), and that takes between 50-100ms in LTE, up to several seconds in 3G, and more in earlier networks.
Figure 7-12. LTE request flow latencies
- Control plane latency: Fixed, one-time latency cost incurred for RRC negotiation and state transitions: <100 ms for idle to active, and <50 ms for dormant to active.
- User plane latency: Fixed cost for every application packet transferred between the device and the radio tower: <5 ms.
- Core network latency: Carrier dependent cost for transporting the packet from the radio tower to the packet gateway: in practice, 30–100 ms.
- Internet routing latency: Variable latency cost between the carrier’s packet gateway and the destination address on the public Internet.
In practice, the end-to-end latency of many deployed 4G networks tends to be in the 30–100 ms range once the device is in a connected state.
So, you have for one request (Figure 8-2. Components of a "simple" HTTP request):
- RRC negotiation 50-2500 ms
- DNS lookup 1 RTT
- TCP handshake 1 RTT (preexisting connection) or 3 RTT (new connection)
- TLS handshake 1-2 RTTs
- HTTP request 1-n RTTs
And with real data:
Table 8-1. Latency overhead of a single HTTP request
| 3G | 4G Control plane | 200–2,500 ms | 50–100 ms DNS lookup | 200 ms | 100 ms TCP handshake | 200 ms | 100 ms TLS handshake | 200–400 ms | 100–200 ms HTTP request | 200 ms | 100 ms Total latency overhead | 200–3500 ms | 100–600 ms
In addition if you have a interactive application that you want to perform moderately ok in a mobile network you can experiment disabling the Nagle algorithm (the kernel waits for data to coalescence into bigger packets instead of sending multiple smaller packets) look for ways to test it in https://stackoverflow.com/a/17843292/869019.
There is the option to read the entire book for free by everyone at https://hpbn.co/ sponsored by Velocity Conference. This is a very highly recommended book, not only to people developing websites, it is useful to everyone who does serve bytes over some network to a client.
Solution 2:
I suspect that a large proportion of the latency you may experience when using "cellular broadband" technologies is a compound issue of a number of things.
There's distance, but as syneticon-dj's mentioned, that's realistically only a very small proportion of the round-trip time.
Here's something to consider... The delays you experience as a customer (especially as a home, or small business customer) are probably artificially induced, at least to some extent. There is a class of 3G and GSM communications for M2M utilisation, for SCADA and so on, which sometimes can provide a greater reliability and lower latency transmission. As a result, they're usually prohibitively expensive.
So basically, you're up against traffic shaping. Either the ISP/Telco is doing it to prioritise better paying customers, or the cell you're connected to is a bit busy, or their entire network is a little bit sluggish (try 00:00 GMT on 1/1/2012, for example).
But there is a way around all of this, it's a bit sneaky though. You'd basically need a TCP connection proxy before your traffic heads out over the mobile WWAN. This proxy would essentially send a spoofed ACK to your application, as the real ACK might be delayed by the ISP's traffic shaping.
It's distinctly dubious, but a number of satellite providers use this mechanism to make the latency seem lower than it actually is.
Solution 3:
Kind of late to the game, but you may want to check out my Performance Calendar's article about the topic: http://calendar.perfplanet.com/2012/latency-in-mobile-networks-the-missing-link/
tl;dr - a major part of mobile latency is due to unoptimized routing on the back-haul.