Very slow accessing a particular remote system.

[jm_paulin]

Hi,

I have this problem when I am using a Remote WebClient to access a PC (like a remote desktop, but over the www). It is definitely a lot slower now than I am on FTTC than it was with my previous internet provider. To give you an idea, the user experience now is as bad as when I plug my cellphone in the laptop and connect using 3G.

How can we go at figuring out what is going wrong ?

Thanks.

JM

[Steve]

Is everything else ok on FTTC? i.e latency and speeds. Do you need ports to be forwarded for the remote desktop if so are they correct?

[jm_paulin]

Everything else is fine. Speed is 37.5/8 Mb, Ping 10ms via speedtest. iPlayer, Sky Anytime or other: no issues.
Same router as before, same rules.. so no changes there. Cannot blame NAT...
I did change the MTU on the PC to 1492 in case, but no significant changes...

It is really like if a particular route to a specific corporate site is really really slow... We are currently using the 3G phone as it is slightly faster...

[Rik]

Sorry, but I can't think of anything to explain it. I'd suggest you have a word with support.

[Glenn]

Are you able to try another remote client, eg, Logmein, there is a free version that you could test with?

[Steve]

If it is an MTU issue using the (trying to remember windows )ping [IP] -f -l [MTU] and look for fragmentation

[jm_paulin]

I did change the MTU to 1492. But that had no effect.

I also contacted support, but did not have much luck there either. "IDNet gives me the best speed possible, the rest is up to the internet and IDNet has no control over it." I can somewhat understand that statement, but I did not have that issue last week when I was using Be to connect to that same site. So there must be something somewhere between IDNet and the www that has changed when I moved from Be.

Could contention ratio be part of it?

I saw that you can have `Traffic Priority` with some of the other more expensive packages. Would this change anything?

[Rik]

It would give you priority at the exchange - most commonly it shows up as lower ping times.

[jm_paulin]

ok. So technically, I moved from LLU to BT back at the exchange...

I guess I can give it a try, but I definitely do not want to be locked for 1 year if that does not help...

Otherwise, my options probably are:
- switch back to Be (what a laugh that would be)
- resign and get another job that only involve remote working to a location that can be reached with a suitable speed

Mind you: resigning is tempting.... got any open position going?

[Rik]

Yes, but you probably wouldn't like the pay here as we're all volunteers.

[jm_paulin]

Ok, so I got my traceroute back from folks on Be.

So Be gets to the network in 10 hops,
Be goes straight to telefonica-wholesale.net (2 hops), & alter.net (5 hops). Rest being not identified.
time to alter.net is around 27ms

IDNet gets to the network in 15 hops
IDNet goes via cogentco.net (7 hops) & alter.net (5 hops). rest being IDNet
time to alter.net is around 160ms

Can that help anyone to understand ?

[Glenn]

JM, do you have an IP, I can run a tracert from my folks TT connection for you to compare.

[jm_paulin]

try 199.67.203.80

[Rik]

I'm timing out:

tracert 199.67.203.80

Tracing route to 199.67.203.80 over a maximum of 30 hops

  1     1 ms     1 ms    <1 ms  192.168.1.254
  2    13 ms    11 ms    11 ms  212.69.63.51
  3    15 ms    11 ms    11 ms  212.69.63.245
  4    13 ms    13 ms    11 ms  149.6.148.205
  5    14 ms    13 ms    13 ms  130.117.50.117
  6    14 ms    11 ms    11 ms  130.117.0.61
  7    89 ms    90 ms    90 ms  154.54.5.122
  8    92 ms    90 ms    92 ms  154.54.44.37
  9    95 ms    95 ms    96 ms  154.54.1.233
10    96 ms    96 ms    98 ms  154.54.41.226
11    97 ms   128 ms    96 ms  154.54.10.226
12    97 ms    96 ms    96 ms  152.63.33.118
13    98 ms    98 ms    98 ms  152.63.43.69
14    99 ms    98 ms   102 ms  152.63.43.78
15   171 ms   177 ms   173 ms  146.188.14.162
16   172 ms   171 ms   171 ms  158.43.233.105
17   177 ms   171 ms   171 ms  158.43.47.174
18     *        *        *     Request timed out.
19     *        *        *     Request timed out.
20     *        *        *     Request timed out.
21     *        *        *     Request timed out.
22     *        *        *     Request timed out.
23     *        *        *     Request timed out.
24     *        *        *     Request timed out.
25     *        *        *     Request timed out.
26     *        *        *     Request timed out.
27     *        *        *     Request timed out.
28     *        *        *     Request timed out.
29     *        *        *     Request timed out.
30     *        *        *     Request timed out.

Trace complete.

ping 199.67.203.80

Pinging 199.67.203.80 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 199.67.203.80:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

[Lance]

This is what I get over my work connection:

P:\>tracert 199.67.203.80

Tracing route to 199.67.203.80 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.133.100.1
  2    <1 ms    <1 ms    <1 ms  10.132.1.13
  3     1 ms     2 ms     1 ms  10.132.1.94
  4    <1 ms    <1 ms    <1 ms  10.132.44.68
  5     1 ms    <1 ms     2 ms  94.101.168.2
  6     7 ms     5 ms     2 ms  94.101.168.249
  7     4 ms     5 ms     2 ms  ge-5-1-670.ipcolo2.London1.Level3.net [212.113.1
0.221]
  8     2 ms     2 ms     7 ms  ae-24-52.car3.London1.Level3.net [4.69.139.100]

  9     2 ms     2 ms     2 ms  mci-level3-ge.london1.Level3.net [4.68.63.154]
10     2 ms     2 ms     2 ms  so-3-2-0.XT1.LND2.ALTER.NET [146.188.3.249]
11     2 ms     2 ms     2 ms  POS6-0.GW3.LND2.ALTER.NET [158.43.233.105]
12     3 ms     3 ms     3 ms  homepage01-gw.customer.uk.uu.net [158.43.47.174]

13     *        *        *     Request timed out.
14     *        *        *     Request timed out.
15     *        *        *     Request timed out.
16     *        *        *     Request timed out.
17     *        *        *     Request timed out.
18     *        *        *     Request timed out.
19     *        *        *     Request timed out.
20     *        *        *     Request timed out.
21     *        *        *     Request timed out.
22     *        *        *     Request timed out.
23     *        *        *     Request timed out.
24     *        *        *     Request timed out.
25     *        *        *     Request timed out.

[jm_paulin]

I do expect the timeout at the end because the end route is heavily firewalled. However, the visible part of the route is quite different...

I am not saying one is wrong, but there is obviously room for better routing once we leave the IDNet network. right?

JM

[pctech]

Just for comparison from a different ISP connection here is a traceroute from me too (connection is ADSL Max on Zen Internet)

Tracing route to 199.67.203.80 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  (first address removed because it is fixed routable IP)
  2    23 ms    23 ms    22 ms  losubs.subs.dsl2.th-lon.zen.net.uk [62.3.84.21]

  3    23 ms    22 ms    22 ms  ae0-114.cr1.th-lon.zen.net.net [62.3.84.185]
  4    22 ms    23 ms    23 ms  sl-gw10-lon-12-019.sprintlink.net [82.195.189.65
]
  5    22 ms    23 ms    22 ms  sl-bb22-lon-9-0-0.sprintlink.net [213.206.128.60
]
  6    23 ms    22 ms    22 ms  sl-bb20-lon-12-0-0.sprintlink.net [213.206.128.5
2]
  7    23 ms    22 ms    23 ms  so-1-2-1.BR2.LND9.ALTER.NET [146.188.35.137]
  8    24 ms    23 ms    23 ms  so-3-2-0.XT2.LND9.ALTER.NET [146.188.5.201]
  9    29 ms    30 ms    30 ms  ge-0-1-0.XT1.LND2.ALTER.NET [146.188.14.161]
10    30 ms    30 ms    29 ms  POS6-0.GW3.LND2.ALTER.NET [158.43.233.105]
11    31 ms    30 ms    30 ms  homepage01-gw.customer.uk.uu.net [158.43.47.174]

12     *        *        *     Request timed out.
13     *        *        *     Request timed out.
14     *        *        *     Request timed out.

[jameshurrell]

Something very odd going on. I am assuming that IP address is physically located in the UK? When I tracert this from my IDNet connection, it appears to cross the pond to the US (hops 7 - 14) and then come back to London (hops 15 and 16). That would be a reason for the delay on remote desktop   :

Tracing route to 199.67.203.80 over a maximum of 30 hops

 1    <1 ms    <1 ms    <1 ms  office.router [192.168.0.1]
 2    26 ms    27 ms    25 ms  telehouse-gw4-lo2.idnet.net [212.69.63.99]
 3    26 ms    27 ms    25 ms  telehouse-gw5-e4-400.idnet.net [212.69.63.245]
 4    27 ms    25 ms    27 ms  gi8-27.mpd01.lon02.atlas.cogentco.com [149.6.148.205]
 5    26 ms    27 ms    27 ms  te1-2.ccr02.lon02.atlas.cogentco.com [130.117.50.117]
 6    25 ms    28 ms    29 ms  te8-3.ccr01.lon01.atlas.cogentco.com [130.117.0.61]
 7   104 ms   103 ms   103 ms  te0-3-0-4.ccr22.bos01.atlas.cogentco.com [154.54.5.122]
 8   103 ms   102 ms   103 ms  te0-3-0-2.ccr21.jfk02.atlas.cogentco.com [154.54.44.45]
 9   111 ms   109 ms   110 ms  te0-1-0-7.ccr21.dca01.atlas.cogentco.com [154.54.26.6]
10   110 ms   111 ms   110 ms  te0-2-0-1.ccr21.iad02.atlas.cogentco.com [154.54.1.78]
11   108 ms   110 ms   109 ms  verizon.iad01.atlas.cogentco.com [154.54.12.46]
12   110 ms   111 ms   109 ms  0.ae2.XL4.IAD8.ALTER.NET [152.63.41.234]
13   113 ms   143 ms   139 ms  0.xe-3-2-0.IL2.DCA6.ALTER.NET [152.63.43.81]
14   113 ms   114 ms   123 ms  0.ge-1-2-0.IL2.DCA4.ALTER.NET [152.63.43.90]
15   190 ms   192 ms   189 ms  so-1-0-0.XT1.LND2.ALTER.NET [146.188.14.217]
16   186 ms   187 ms   188 ms  POS0-0.GW3.LND2.ALTER.NET [158.43.233.109]
17   189 ms   189 ms   187 ms  homepage01-gw.customer.uk.uu.net [158.43.47.174]
18     *        *        *     Request timed out.
19     *        *    

From a BT retail connection, it remains in the UK.

Something amiss somewhere, but it looks like a problem between Cogent and Alter.net...

[Steve]

Sounds like a good question to ask to support.

[pctech]

Does appear to take a rather long way round but to be fair to IDNet this is due to Cogent's routing policy for that particular network/IP

[jameshurrell]

Does appear to take a rather long way round but to be fair to IDNet this is due to Cogent's routing policy for that particular network/IP

Agreed.

[Lance]

IDNet should be able to get the routing changed if you ask them and show them the tracert.

[sof2er]

From my experience with previous ISP's and IDNet if I had a ping problem it always ended up with a hop involving cogentco...

[jm_paulin]

Just called IDNet support.

Looks like they will take a copy of the traceroute in this thread and send that to Cogent. I guess we can only wait to see if cogent can act on it....

Thanks to all the traceroute from the various Internet provider in this thread.

JM

[Rik]

Glad we could help. Let us know how it goes.

[Technical Ben]

Glad to see you got the fix in motion!
I understand it's not great to have a response saying there is nothing that can be done. But glad that IDNet was able to sort it when given the full details. 

[jm_paulin]

Not sure if the fix is really in motion. It was more like `well, I guess we can send a mail and see what they say, if they say anything at all`. Did not sound very hopeful to get anything back. But at least this is a step in a more positive direction.

I would have been a lot happier with `yeah, let's ditch Cogent and write a special route just because you are such a special customer for us` 

I know I can dream, but hopefully it will settle somewhere in the middle... I soon as we can get it working before I explode my TMobile allowance......

JM

[pctech]

Unfortunately I don't think Cogent will change their routing policy just for IDNet.

[Rik]

But IDNet have been known to route around a problem themselves.

[Simon_idnet]

We have now routed around this problem.

[Glenn]

Thanks, Simon.

[jm_paulin]

Simon rocks!

JM

[Rik]

See, I told you.