Internet in China Post-earthquake

After getting back to China on New Year’s Day, I noticed that the Internet connections have not come back as quickly as those in Singapore. After two days of spotty connections in the city-state, the net was largely back to very quick speeds. But here in Beijing, there are still many quirks.

In many cases, “triangle” routing seems to work better than direct connections. That is, using a VPN to a server in the US to redirect traffic often gave higher throughput than direct contact with sites.

For example, downloading Apple’s 10.4.8 OS update, at around 28 Mbytes:

• Direct connection from China Netcom (CNC) DSL to Apple.com : 58 minutes
• “Triangle routed” from CNC to VPN in US to Apple.com : 15 minutes

This could be due to any number of factors: the interconnection of CNC with the VPN provider might be better than that of CNC to Apple.com directly. This is likely the case. Another example of triangle routing doing better — Google Mail is extremely slow to access directly from CNC. But if I use a VPN or SSH tunnel, it is much faster.

But I also do wonder if certain chokepoints of the Great Firewall are affected by increased traffic suddenly being funneled through systems that weren’t designed for so much load. In that case, would the opaque encrypted VPN packets be shuttled across the GFW interface faster than transparent FTP or HTTP packets? Since it makes no sense to inspect an strongly encrypted packet, it may get passed along with less hassle. And since the GFW system works on filtering cleartext streams, might some outside connections be throttled?

One bright spot: I have good enough packet throughput to do a Skype videoconference with folks in Singapore. The video was not frivilous, as I visually instructed my 10-year old niece how to connect a new Canon photo printer to their PC. It was much easier to show her the USB A-to-B cable on video, than to describe it by phone. Chalk one up for videoconferencing.

If you’re really into the geek speak, you can see the following addendum…

TRACEROUTE results

Interestingly, using traceroute reveals lots of delay just within CNC’s own network (600 millisenconds) and resulting in a direct connection to Google’s network. From my DSL connection in Beijing, all the 219.158.x.x addresses are CNC, and the 66.249.x.x are Google addresses:

5 bt-229-021.bta.net.cn (202.106.229.21) 8.842 ms 20.276 ms 8.896 ms
6 202.96.12.25 (202.96.12.25) 9.071 ms 8.884 ms *
7 219.158.4.158 (219.158.4.158) 147.837 ms 219.158.4.54 (219.158.4.54) 52.776 ms 53.859 ms
8 219.158.3.78 (219.158.3.78) 50.977 ms 50.919 ms 219.158.3.70 (219.158.3.70) 53.490 ms
9 219.158.25.118 (219.158.25.118) 537.867 ms 542.838 ms *
10 219.158.25.113 (219.158.25.113) 545.800 ms 540.884 ms *
11 219.158.25.206 (219.158.25.206) 667.415 ms 599.034 ms 601.001 ms
12 * * 66.249.94.2 (66.249.94.2) 608.553 ms
13 66.249.95.135 (66.249.95.135) 645.602 ms 623.624 ms *

The traceroute from my DSL connection to the SSH tunnel provider shows much better numbers. The Sprintlink hops seem to be Mexico-Los Angeles:

5 bt-229-065.bta.net.cn (202.106.229.65) 9.253 ms 8.301 ms 8.820 ms
6 202.96.12.45 (202.96.12.45) 8.945 ms 8.846 ms 202.96.12.53 (202.96.12.53) 8.755 ms
7 219.158.4.154 (219.158.4.154) 39.221 ms 219.158.4.158 (219.158.4.158) 50.467 ms 68.572 ms
8 219.158.3.114 (219.158.3.114) 37.776 ms 51.532 ms 219.158.3.74 (219.158.3.74) 49.860 ms
9 sl-gw29-ana-3-0.sprintlink.net (144.232.54.73) 538.758 ms * 533.456 ms
10 sl-bb20-ana-10-0.sprintlink.net (144.232.1.145) 537.000 ms * 571.959 ms
11 sl-bb21-ana-14-0.sprintlink.net (144.232.1.170) 550.512 ms 557.068 ms 532.238 ms
12 * sl-st20-la-11-0.sprintlink.net (144.232.8.94) 605.971 ms 664.588 ms
13 so-1-0-0.gar1.losangeles1.level3.net (64.152.193.73) 526.839 ms 548.353 ms 538.671 ms

Related posts:

This entry was posted on Wednesday, January 3rd, 2007 at 10:33 pm and is filed under Asia, China, Technology, GFW. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.