[TelstraClear] TelstraClear Cable connections appear to be rate shaped in one way or another

Forums › One New Zealand (including Vodafone, WxC, Farmside) › [TelstraClear] TelstraClear Cable connections appear to be rate shaped in one way or another

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 12

176 posts

Master Geek

#524623 22-Sep-2011 14:00

Talkiet: The 100% honest answer is that I don't know... I'm relatively sure that ANY level 1 helpdesk from any ISP would be flummoxed by this clearly complicated or subtle issue. I have worked on issues before where unexpected performance (that was still well in excess of what would be considered reasonable BB performance) was observed - just because it was unexpected... Often unexpected performance is an early indicator of a problem, even if at an absolute level it's still fine for 99.99% of people.

Have you tried using this:

http://wand.net.nz/~perry/max_download.php

Plug in the values you know and see what you get...

Cheers - N

Plugging in my default window size of 131071 bytes and the observed ping of 159ms gives a result of about 6.5mbit/sec.

While I appreciate the link (it's better presented than I've seen thus far), it's just doing the match that was explained early on in this thread.

The fact of the matter is that I don't see 6.5mbit/sec, which I would expect with no tweaking. And I have taken the window way up to 512k (and at places in between) - which should be good for some 33mbit/sec (which is beyond the capability of my connection).

The fact of the matter is I've only seen better performance by running multiple connections.

TC (Gary) has stated again and again that they do not shape packets. Their BB & Media architect has reiterated they do not mess with packets in any way. TCPDumps confirm the sliding window TCP options arrive intact. I've done about every test that can be done without having deep access to TC's network.

Oh, and I think you've earned the retraction and apology I offered above. :-)

Norton

Get easy to use, easy to install Norton antivirus protection against advanced online threats (affiliate link).

jnawk

176 posts

Master Geek

#524624 22-Sep-2011 14:03

Just been showed this:

http://www.ispmap.co.nz/topmap.html

Not sure how up-to-date it is.

Beccara

1467 posts

Uber Geek

ID Verified

#524632 22-Sep-2011 14:22

jnawk:
Talkiet: The 100% honest answer is that I don't know... I'm relatively sure that ANY level 1 helpdesk from any ISP would be flummoxed by this clearly complicated or subtle issue. I have worked on issues before where unexpected performance (that was still well in excess of what would be considered reasonable BB performance) was observed - just because it was unexpected... Often unexpected performance is an early indicator of a problem, even if at an absolute level it's still fine for 99.99% of people.

Have you tried using this:

http://wand.net.nz/~perry/max_download.php

Plug in the values you know and see what you get...

Cheers - N

Plugging in my default window size of 131071 bytes and the observed ping of 159ms gives a result of about 6.5mbit/sec.

What OS are you running to get a default window size of 128k? Windows is 64k

Most problems are the result of previous solutions...

All comment's I make are my own personal opinion and do not in any way, shape or form reflect the views of current or former employers unless specifically stated

DonGould

3892 posts

Uber Geek

#524633 22-Sep-2011 14:24

jnawk: DonGould pointed out it is the ISP's responsibility to manage the upstream provider.

I don't recall exactly what I did say, but I will say this....

My preference is that my provider deals with it's upstreams rather than me having to deal directly because there is only a very limited number of people in that space and if every user having a problem started dealing directly with people like the general manager for IP of the largest telco in the region to fix things daily then he'd get nothing done at all.

Having said that, getting traction to get inter carrier faults fixed is not easy and you do have to have both determination and some clue factor which does bring us back to the point above.

Level 1 need to take good ownership and deal with problems and actually escalate things and follow up those escalations though the ranks on behalf of the customer or we end up as we have here on GZ with dozens and dozens of posts from clearly unhappy users planning tests of their own and raking up technical staff from other providers across the industry who quickly become defensive and annoy and less inclined to help people at all.

Contary to what Neil suggests above, intercarrier issues can be fixed and quite quickly when every carrier takes ownership. There are many mailing lists to get things done quickly as well as back channels.

The last time I had to deal with a problem I simply ran a trace route, posted on international nog lists, ran a number of tests, called for assistance and got on the phone to all the providers in the chain and explained to them why it was in their interests to step up and sort it. This is normally the roll of peering managers within providers.

Network operators complain when their mailing lists start to fill up with end users. I've commented about this on NOG lists in the past that if they want user discussion on GZ and not their lists then they need to ensure that Level 1 staff are empowered and allowed to track and follow up customers properly and not just fob us off.

Promote New Zealand - Get yourself a .kiwi.nz domain name!!!

Check out mine - i.am.a.can.do.kiwi.nz - don@i.am.a.can.do.kiwi.nz

jnawk

176 posts

Master Geek

#524635 22-Sep-2011 14:27

Beccara: What OS are you running to get a default window size of 128k? Windows is 64k

Not Windows ;-)

I've mentioned this already - openSUSE 11.4 64-bit.

jnawk

176 posts

Master Geek

#524637 22-Sep-2011 14:30

jpollock:
Talkiet:?

Could you ask TCL to supply you a link of a file hosted somewhere near the edge of their network? That way you can see what sort of performance you can get across the network that they themselves have control over.

If it turns out that a configuration choice of an external provider is limiting your per thread throughput, there's realistically very little that could be done about it... That's the way the Internet works.

Cheers - N

The problem is that if the latency dropped to 35ms, the throughput would go up to 14Mbps, so it's really only obvious when you leave the network.

Speed tests to anywhere in NZ other than Wellington (which is really LA) get good speeds. (speedtest.net)

Beccara

1467 posts

Uber Geek

ID Verified

#524638 22-Sep-2011 14:38

jnawk:
Beccara: What OS are you running to get a default window size of 128k? Windows is 64k

Not Windows ;-)

I've mentioned this already - openSUSE 11.4 64-bit.

Right well hate to say this but the TCP Window Size in the header is a 16bit field for a max of 64k, any bigger and you need window scaling which is hit and miss on the net, I've pointed out that your host has a different internal network path for XNet and Telstra which could be the cause the scale factor of the packet to be set to 0 or simply modifying the packet.

I'm very interested in Telstra's response to this as if the issue isn't a miss configured router in their network then the issue becomes next to impossible to fix due to the number of potential parties involved. Have you spoken to your hosting provider at all?

Out of interest have you change the SSH port that the remote server is using and done the tests again?

jnawk

176 posts

Master Geek

#524643 22-Sep-2011 14:46

Beccara: Right well hate to say this but the TCP Window Size in the header is a 16bit field for a max of 64k, any bigger and you need window scaling which is hit and miss on the net, I've pointed out that your host has a different internal network path for XNet and Telstra which could be the cause the scale factor of the packet to be set to 0 or simply modifying the packet.

Have you read all my posts on this thread? I've already pointed out the SYN packet arrives with window scale options intact exactly as it was sent.

At any rate, it was established that my machine on my friend's XNet connection got ~10mbit/sec (= window scaling *has* to be intact for that speed at 150msec latency)

Beccara: Out of interest have you change the SSH port that the remote server is using and done the tests again??

Yes, run on both port 22 and port 2222. No changes.

Beccara

1467 posts

Uber Geek

ID Verified

#524647 22-Sep-2011 14:53

jnawk:
Beccara: Right well hate to say this but the TCP Window Size in the header is a 16bit field for a max of 64k, any bigger and you need window scaling which is hit and miss on the net, I've pointed out that your host has a different internal network path for XNet and Telstra which could be the cause the scale factor of the packet to be set to 0 or simply modifying the packet.

Have you read all my posts on this thread? I've already pointed out the SYN packet arrives with window scale options intact exactly as it was sent.

At any rate, it was established that my machine on my friend's XNet connection got ~10mbit/sec (= window scaling *has* to be intact for that speed at 150msec latency)

I have read your posts but your connection on Telstra exhibits all the signs of a 64k window with no scaling, If the SYN packet states scaling options like you say then and changes to the packet in the middle would result in different symptoms than this. Try doing a packet capture to a pcap file on the server as you download and fire it up in wireshark

jnawk

176 posts

Master Geek

#524649 22-Sep-2011 15:05

Beccara: I have read your posts but your connection on Telstra exhibits all the signs of a 64k window with no scaling, If the SYN packet states scaling options like you say then and changes to the packet in the middle would result in different symptoms than this. Try doing a packet capture to a pcap file on the server as you download and fire it up in wireshark

Been there, done that. Even posted the results, thought I can't remember if I posted them to the TC dude privately, or here. The nuts and bolts of it is that the window scales out to a whopping 1MB for my box and 2MB for the other dude's box.

Obviously I've ascertained this result by sampling the ACK packets rather than looking at 'em all. I could write a script, but it seems unnecessary.

jpollock

600 posts

Ultimate Geek

Trusted

#525063 23-Sep-2011 15:05

jnawk:
jpollock: Any updates??

Watch this space - Garry asked for me to give them until Friday. You'll know the outcome here first.

So... It's Friday. ;)

---
http://blog.jason.pollock.ca

jnawk

176 posts

Master Geek

#525066 23-Sep-2011 15:20

Indeed. TC cannot find any problems at their end. UDP blazes out of the box at some 92MBit/sec, but TCP at a miserly 3.5MBit/sec. They are going to talk to their upstream provider...

In the mean time, it might be time to introduce the box in Germany...

jnawk

176 posts

Master Geek

#525075 23-Sep-2011 15:38

For the interested - here are the paths for the new box..

tc-box$ tracepath -n 78.47.220.71

1: x.x.x.y 0.538ms pmtu 1500
1: x.x.x.z 0.678ms
2: no reply
3: 218.101.61.124 asymm 4 15.017ms
4: no reply
5: 203.98.50.1 asymm 4 22.391ms
6: 203.98.50.251 asymm 5 21.913ms
7: 203.167.233.10 asymm 6 35.085ms
8: 202.84.142.114 asymm 7 153.227ms
9: 202.84.251.242 asymm 8 151.983ms
10: no reply
11: 4.69.144.254 asymm 13 147.302ms
12: 4.69.137.37 asymm 14 147.965ms
13: 4.69.132.82 asymm 16 240.841ms
14: 4.69.134.190 asymm 15 223.267ms
15: 4.69.134.157 asymm 14 234.196ms
16: 4.69.137.53 asymm 15 314.389ms
17: 4.69.143.137 asymm 18 320.169ms
18: 4.69.140.6 asymm 17 318.024ms
19: 4.69.154.199 315.744ms
20: 212.162.40.206 303.100ms
21: 213.239.240.242 asymm 20 321.083ms
22: 213.239.224.136 asymm 21 311.140ms
23: 46.4.90.150 asymm 22 309.900ms
24: 78.47.220.71 asymm 23 325.665ms reached
Resume: pmtu 1500 hops 24 back 23

xnet-box$ tracepath -n 78.47.220.71

1: x.x.x.y 0.430ms pmtu 1500
1: x.x.x.z 1.405ms
1: x.x.x.z 1.068ms
2: x.x.x.z 1.076ms pmtu 1492
2: 182.154.0.21 36.367ms asymm 3
3: no reply
4: 114.31.203.89 33.154ms
5: 114.31.202.43 157.579ms asymm 9
6: 114.31.202.88 33.967ms
7: 114.31.202.45 157.693ms
8: 206.223.143.85 165.866ms
9: 82.197.168.70 252.087ms
10: 77.109.140.193 307.897ms
11: 77.109.128.149 329.564ms
12: 77.109.128.153 340.936ms asymm 11
13: 213.239.240.247 336.424ms asymm 14
14: 213.239.224.136 339.819ms asymm 16
15: 46.4.90.150 337.856ms asymm 17
16: 78.47.220.71 322.144ms reached
Resume: pmtu 1492 hops 16 back 48

XNet box again gets 1.1mbytes/sec, TC box gets 300kbytes/sec

jnawk

176 posts

Master Geek

#525121 23-Sep-2011 17:15

For those who want symbolic names...

My box to the USA box is TC as far as hop 6, Reach is hop 8 & 9, coresite #1, webnx #12.
My box to the German box is the same until Reach @ hop 8, hop 11 through 20 are Level3, 21 & 22 are Hetzner, and 23 is bettervps.

My friends box is XNet at hop 2, vocus till hop 7, and for the USA, webnx at hop 10, while for germany, init7 at hop 8, hetzner at 13, bettervps at hop 15.

Also, the TC dude seems to think the issue was performance to the box in the USA, not performance in general. *grumble*

jpollock

600 posts

Ultimate Geek

Trusted

#525158 23-Sep-2011 18:38

It's performance in general. Witopia and other VPN providers exhibit the same behaviour, as does Amazon EC2.

---
http://blog.jason.pollock.ca

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 12