[TelstraClear] Intermittent 40s wait, is TelstraClear proxy the cause?

Forums › One New Zealand (including Vodafone, WxC, Farmside) › [TelstraClear] Intermittent 40s wait, is TelstraClear proxy the cause?

heapsort

245 posts

Master Geek

Lifetime subscriber

#105805 11-Jul-2012 09:25

My home internet is TelstraClear cable in Christchurch (low-end user, under 20GB a month and could easily live with less than the 15Mbps download speed) and we have a problem that I am fairly sure is caused by ISP transparent proxy mechanisms.

For some weeks now, seeming worse recently, we've noticed occasional slow page load times - but only for a certain set of websites that have some static page components hosted outside NZ. The most noticeable one for us is newspapers under stuff.co.nz. Normal page loads will be fast, but the long ones will be blank page for up to a minute. We can go days without noticing, then get several a day.

Every time I have turned on Firefox plugin Firebug and caught a Stuff slow load in the act, it has been waiting between 40 and 41 seconds for files from static2.stuff.co.nz. Now, a traceroute shows stuff.co.nz and static.stuff.co.nz are served by trademe.co.nz servers, but static2.stuff.co.nz goes offshore. Browsing other news sites to compare, I found on nz.yahoo.com intermittent instances of files from yimg.com taking just over 40 seconds to fetch. Different site, same amount of delay.

I also reproduced the problem from a script, eliminating browser configuration as the cause: fetching tiny files from static2.stuff.co.nz and l.yimg.com, found about 99% of fetches took under 1 second, most of the other 1% were between 40 and 41 seconds. During a 40s wait for a file, traffic to other sites is unaffected so I'm confident it is not a problem with my configuration or hardware. A brief comparative test on an Internet connection at my work (not through TelstraClear) has not produced any 40s wait there yet.

Has anyone else noticed anything similar? Any insight to confirm or refute my conclusion that it is caused by the TelstraClear proxy?

Crankshaw

5 posts

Wannabe Geek

#653994 11-Jul-2012 13:45

Hi Heapsort,

A quick look from my TCL (dsl, but shouldn't matter) connection shows this as being an akamai hosted domain:

$ host static2.stuff.co.nz
static2.stuff.co.nz is an alias for static2.stuff.co.nz.edgesuite.net.
static2.stuff.co.nz.edgesuite.net is an alias for a1784.g.akamai.net.
a1784.g.akamai.net has address 203.167.141.153
a1784.g.akamai.net has address 203.167.141.155

The particular addresses I was given by DNS are domestically hosted and thus would not pass through the caches. So, usual questions apply:

What dns servers are you using? (for CDN's in general you should use your ISPs DNS servers, services like opendns break dns based CDN's).
Can you post a traceroute into here so we can see where it's going?
Is this time of day dependant?

(disclaimer: I work for TCL but am not posting in any form of official capacity. Merely curious.)

heapsort

245 posts

Master Geek

Lifetime subscriber

#654007 11-Jul-2012 14:23

Thanks for the reply and curiosity, Crankshaw. Here's more info.

DNS on our router is 203.97.78.43.

$ host static2.stuff.co.nz
static2.stuff.co.nz is an alias for static2.stuff.co.nz.edgesuite.net.
static2.stuff.co.nz.edgesuite.net is an alias for a1784.g.akamai.net.
a1784.g.akamai.net has address 203.69.138.17
a1784.g.akamai.net has address 203.69.138.32

$ traceroute static2.stuff.co.nz
traceroute to static2.stuff.co.nz (203.69.138.17), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) 0.275 ms 0.222 ms 0.223 ms
2 * * *
3 218.101.61.101 (218.101.61.101) 21.013 ms 20.917 ms 20.804 ms
4 ie2-g-0-0-0.telstraclear.net (203.98.50.2) 28.383 ms 28.754 ms 27.837 ms
5 ge-0-2-0-1.xcore1.acld.telstraclear.net (203.98.50.251) 27.996 ms 28.167 ms 32.449 ms
6 210.80.27.5 (210.80.27.5) 32.558 ms 28.116 ms 27.881 ms
7 0.xo-1-0-0.XT3.AKL1.ALTER.NET (210.80.35.9) 28.026 ms 23.882 ms 29.168 ms
8 210.80.49.38 (210.80.49.38) 179.951 ms 176.825 ms 176.422 ms
9 203.103.244.138 (203.103.244.138) 207.361 ms 212.262 ms 212.084 ms
10 TPDT-3011.hinet.net (220.128.1.162) 198.700 ms 198.468 ms 198.276 ms
11 tyfo-3011.hinet.net (220.128.8.81) 198.853 ms 202.881 ms 201.456 ms
12 tyfo-3301.hinet.net (220.128.8.249) 199.477 ms 194.743 ms 196.655 ms
13 203-69-138-17.HINET-IP.hinet.net (203.69.138.17) 200.242 ms 193.116 ms 198.524 ms

timmmay

20580 posts

Uber Geek

Trusted

Lifetime subscriber

#654015 11-Jul-2012 14:30

Looks like TC isn't routing to akami properly then.

nickt

90 posts

Master Geek

#654018 11-Jul-2012 14:35

More likely that Akamai sometimes routes outside the country. I get 203.167.141.153/203.167.141.155 right now, like Crankshaw, which with a ping of 50ms is still inside NZ.

wallop

367 posts

Ultimate Geek

#654053 11-Jul-2012 15:43

I get the same with stuff.co.nz using Telecom dsl. In Christchurch as well. I'm also using unblock-us, are you using them?

heapsort

245 posts

Master Geek

Lifetime subscriber

#654058 11-Jul-2012 16:00

wallop: I get the same with stuff.co.nz using Telecom dsl. In Christchurch as well. I'm also using unblock-us, are you using them?

I'm not using unblock-us (hadn't even heard of it until your reply) - I guess from first glance it is a service that gives you access to location-restricted streams but has to use a custom DNS to achieve that?

I'm using the standard recommended TCL DNS server as far as I am aware. We don't use internet to watch video much, and haven't yet found any need for such a service, but I could guess it might be what is causing a similar problem to some websites for you.

timmmay

20580 posts

Uber Geek

Trusted

Lifetime subscriber

#654094 11-Jul-2012 16:55

I'm on TC cable, I'm getting a 20ms ping

tracert static2.stuff.co.nz

Tracing route to a1784.g.akamai.net [203.167.141.155]
over a maximum of 30 hops:

1 <1 ms 1 ms <1 ms HomeGateway [192.168.1.1]
2 * * * Request timed out.
3 10 ms 9 ms 10 ms lo0.internet.ivpn.pe25.telstraclear.net [218.101.61.124]
4 19 ms 19 ms 19 ms 203.97.86.195
5 21 ms 20 ms 18 ms 203.167.141.155

Tradepub

Free professional, reference and technical white papers (affiliate link).

heapsort

245 posts

Master Geek

Lifetime subscriber

#654111 11-Jul-2012 17:35

Interesting, thanks for that.

I finally got the idea of switching the DNS setting on my router from 203.97.78.43 to .44 ... and now I also get very fast traceroutes in just a few hops to the sites that were giving me the 40 second intermittent waits, static2.stuff.co.nz and l.yimg.com.

Yay! Will see if it stays that way.

Guess there's some issue currently showing up on TCL DNS server .43 not on .44 maybe.

[Update - no, it didn't last any more than minutes. Still on the .44 DNS server, but now I'm again getting to a traceroute static2.stuff.co.nz going through hinet.net and intermittent 40 second wait to fetch a file from there.]

My router also seems to only provide a single DNS server setting, so I can't set .43 as primary and .44 as secondary - have to manually choose one or the other. Time for a better router perhaps?

timmmay

20580 posts

Uber Geek

Trusted

Lifetime subscriber

#654128 11-Jul-2012 18:41

On your PC you could manually set your DNS server(s), but that won't help anything on WiFi or other PCs.

nickt

90 posts

Master Geek

#654187 11-Jul-2012 21:04

Your choice of TCL DNS server shouldn't make any difference, it comes down to what Akamai thinks is the best server to provide the content. It seems as if every now and again they send you off to Taiwan (203.69.138.17) instead of the machines TCL hosts (203.167.141.153 & 155), but even still 40 seconds is a smidgen broken. It would be interesting to know if Telstra inserts the proxy for this traffic too.

Does your script correlate the 40s waits with talking to Taiwan, and < 1s for NZ ? Perhaps you could try to rule out the proxy by adding headers to your requests.

heapsort

245 posts

Master Geek

Lifetime subscriber

#654372 12-Jul-2012 10:19

nickt: Your choice of TCL DNS server shouldn't make any difference, it comes down to what Akamai thinks is the best server to provide the content. It seems as if every now and again they send you off to Taiwan (203.69.138.17) instead of the machines TCL hosts (203.167.141.153 & 155), but even still 40 seconds is a smidgen broken. It would be interesting to know if Telstra inserts the proxy for this traffic too.

Does your script correlate the 40s waits with talking to Taiwan, and < 1s for NZ ? Perhaps you could try to rule out the proxy by adding headers to your requests.

Thanks for the suggestion. When it's resolving the Akamai address to an NZ server, the fetch time is consistently under 0.1 seconds. When it's having to get it from Taiwan, most fetches of the same tiny file are around 0.5 seconds and the occasional one takes 40 to 41 seconds.

Today it is consistently behaving, resolving those static content sites to NZ servers, so I can't get any more information.