Why is Tiscali dropping packets?

[#1]

I am trying to get some work done which involves me connecting via ssh to servers in the US.  At busy times the connection becomes painfully slow, like a 5-6 seconds delay from a single keystroke to seeing a response on my terminal.  I tried to troubleshoot it and found out that going from UK to US, Tiscali are more than trebling the delay over a single hop (from London to Germany): 

2  lo0-plusnet.pte-ag2.plus.net (195.166.128.72)  39.538 ms  42.419 ms  42.911 ms
 3  ge0-0-0-504.pte-gw2.plus.net (84.92.4.90)  43.396 ms  43.893 ms  44.823 ms
 4  vl23.thn-gw2.plus.net (212.159.4.20)  46.875 ms  50.711 ms  53.082 ms
 5  xe-1-1-0-0.lon10.ip.tiscali.net (213.200.78.69)  54.552 ms  62.540 ms  63.025 ms
 6  xe-2-0-0.was12.ip.tiscali.net (89.149.185.9)  159.578 ms xe-4-0-0.was12.ip.tiscali.net (89.149.185.13)  138.048 ms xe-2-0-0.was12.ip.tiscali.net (89.149.185.9)  138.784 ms
 7  213.200.84.118 (213.200.84.118)  138.773 ms  120.714 ms  110.808 ms
 8  pos-0-15-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.69)  155.798 ms  156.281 ms  156.770 ms

Ping-ing the two successive Tiscali routers gives me:
From London:

$ ping -c 3 213.200.78.69
PING 213.200.78.69 (213.200.78.69) 56(84) bytes of data.
64 bytes from 213.200.78.69: icmp_seq=1 ttl=60 time=28.9 ms
64 bytes from 213.200.78.69: icmp_seq=2 ttl=60 time=44.8 ms
64 bytes from 213.200.78.69: icmp_seq=3 ttl=60 time=22.3 ms
--- 213.200.78.69 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 22.352/32.040/44.839/9.440 ms

From Germany:

$ ping -c 3 89.149.185.9
PING 89.149.185.9 (89.149.185.9) 56(84) bytes of data.
64 bytes from 89.149.185.9: icmp_seq=1 ttl=59 time=109 ms
64 bytes from 89.149.185.9: icmp_seq=2 ttl=59 time=106 ms
64 bytes from 89.149.185.9: icmp_seq=3 ttl=59 time=152 ms
--- 89.149.185.9 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 106.659/122.818/152.708/21.158 ms

This is not merely a firewall issue dropping icmp packets.  The same happens with tcptraceroute.
Same deal coming back from US to UK:

 7  pos-0-4-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.26)  28.967 ms  30.171 ms  28.506 ms
 8  pos-0-4-0-0-cr01.chicago.il.ibone.comcast.net (68.86.85.165)  45.953 ms  45.803 ms  44.479 ms
 9  xe-2-1-0.chi10.ip.tiscali.net (77.67.68.37)  49.983 ms  51.319 ms  49.974 ms
10  xe-2-0-0.lon20.ip.tiscali.net (89.149.186.85)  143.047 ms  141.404 ms  141.515 ms

Hop 8 is in the US, hop 9 in Germany in just over 5ms and then from Germany to the UK takes more than an additional 91ms!
Any idea why this is happening?  Can it be fixed?

[#2]

That does indeed look nasty Mick and might be something that PN need to take up with Tiscali
Never having used a Tiscali consumer  connection I don't know what route over their network US-bound traffic takes as one possible reason maybe just load on this particular route I suppose bearing in mind it is Sunday evening, though I'm sure as a transit customer PN's traffic is tagged as high priority but I bet they aren't the only transit customer so contention might be high.
I would expect they keep traffic on their own backbone for a long as possible to save money (and comcast dont appear to be a LINX member so maybe peering in London isn't an option)
I hope you get a response but something tells me if might be just due to time of day I'm afraid.
If you'd like help with running any more tests give me a shout, I'll be happy to help
Edit to add some detail
I'm seeing similar to your results although I'm on a different edge router to you. (tracert run to last router shown in your snapahot in Atlanta
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Admin>tracert 68.56.85.69
Tracing route to c-68-56-85-69.hsd1.fl.comcast.net [68.56.85.69]
over a maximum of 30 hops:
  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2    28 ms    31 ms    33 ms  lo0-plusnet.pte-ag1.plus.net [195.166.128.64]
  3    28 ms    35 ms    27 ms  ge0-0-0-403.pte-gw2.plus.net [84.92.4.2]
  4    27 ms    31 ms    27 ms  vl23.thn-gw2.plus.net [212.159.4.20]
  5    34 ms    27 ms    27 ms  xe-1-1-0-0.lon10.ip.tiscali.net [213.200.78.69]
  6  108 ms  109 ms  107 ms  xe-1-0-0.was12.ip.tiscali.net [89.149.185.5]
  7  110 ms  119 ms  111 ms  213.200.84.118
  8  117 ms  115 ms  119 ms  pos-0-7-0-0-cr01.charlotte.nc.ibone.comcast.net
[68.86.85.217]
  9  126 ms  123 ms    *    68.86.90.190
10  133 ms  133 ms  161 ms  68.85.219.17
11  131 ms  183 ms  131 ms  68.85.210.126
12  134 ms  167 ms  175 ms  te-8-4-ar01.bonitasprngs.fl.naples.comcast.net [
68.87.236.101]
13  145 ms  141 ms  137 ms  te-8-1-ar02.venice.fl.westfl.comcast.net [68.87.
238.14]
14  133 ms  133 ms  149 ms  te-8-1-ur01.northport.fl.westfl.comcast.net [68.
87.238.26]
15  144 ms  135 ms  147 ms  te-9-1-ur01.portcharlott.fl.westfl.comcast.net [
68.87.238.66]
16  148 ms  147 ms  141 ms  te-8-2-ur01.murdock.fl.westfl.comcast.net [68.87
.238.70]
17  144 ms  137 ms  135 ms  ge-0-1-ubr02.murdock.fl.westfl.comcast.net [68.8
7.239.2]
18    *        *        *    Request timed out.
19    *        *        *    Request timed out.
20    *        *

and a tracetcp gives me
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Admin>tracetcp 68.86.85.69
Tracing route to 68.86.85.69 [pos-0-15-0-0-cr01.atlanta.ga.ibone.comcast.net] on
port 80
Over a maximum of 30 hops.
1      2 ms    2 ms    2 ms    192.168.0.1
2      33 ms  31 ms  47 ms  195.166.128.64  [lo0-plusnet.pte-ag1.plus.net]
3      30 ms  29 ms  29 ms  84.92.4.2      [ge0-0-0-403.pte-gw2.plus.net]
4      31 ms  30 ms  28 ms  212.159.4.20    [vl23.thn-gw2.plus.net]
5      34 ms  32 ms  32 ms  213.200.78.69  [xe-1-1-0-0.lon10.ip.tiscali.net
]
6      116 ms  106 ms  100 ms  89.149.187.66  [xe-1-0-0.nyc30.ip.tiscali.net]
7      114 ms  100 ms  104 ms  68.86.89.177
8      110 ms  112 ms  116 ms  68.86.85.93    [pos-0-14-0-0-cr01.mclean.va.ibo
ne.comcast.net]
9      Destination Reached in 142 ms. Port closed on 68.86.85.69
Trace Complete.

[#3]

Thank you techguy,

Quote from: techguy

I hope you get a response but something tells me if might be just due to time of day I'm afraid.

Time of day has probably little to do with it, other than general delay across all hops.  Here we are talking about an incremental latency between London and Germany which is 19 times greater than previous or successive hops on the route.  This tells me something is broken at Tiscali International - which as a Tier 2 provider is probably not acceptable.  So, have they stopped paying their bill to VNSL/Sprint, or are they trying to squeeze more than what their current pipes will fit?
I'm going to also try it out early in the morning when both UK & US are asleep and see what I get.

[#4]

Could be just a router reboot required somewhere.
Perhaps am reading wrong but looks like Tiscali peer directly with comcast so not sure where sprint come in or does your traffic to these servers usually hand off to sprint?

[#5]

As I understand it Tiscali buys Tier 1 connections from Sprint.  That's how they cross the pond.  Unless someone has access to all their agreements which are shrouded in secrecy I am just guessing.
Anyhow, that's not really my (end user) problem.  As you say it could just be that they need to reboot a rooter - ha, ha!  Can you believe taking down half the Internet every time?  I think that at their level they must surely have more advance equipment than this!

[#6]

Hi Mick
Is this any use http://www.ip.tiscali.net/
I'd imagine PN can only raise a fault if the problem is directly with their connection to Tiscali as opposed to a Tiscali internal routing issue which is why noone from PN has responded (or they could be on the case and waiting for a response from Tiscali)

[#7]

Quote from: MickKi

I am trying to get some work done which involves me connecting via ssh to servers in the US.  At busy times the connection becomes painfully slow, like a 5-6 seconds delay from a single keystroke to seeing a response on my terminal.

Are you using default ports for the SSH connection? If not, you might be falling foul of our traffic management platform. You're asking why Tiscali are dropping packets yet all of your traces show 0% packet loss 

Quote

I tried to troubleshoot it and found out that going from UK to US, Tiscali are more than trebling the delay over a single hop (from London to Germany): 2  lo0-plusnet.pte-ag2.plus.net (195.166.128.72)  39.538 ms  42.419 ms  42.911 ms 3  ge0-0-0-504.pte-gw2.plus.net (84.92.4.90)  43.396 ms  43.893 ms  44.823 ms 4  vl23.thn-gw2.plus.net (212.159.4.20)  46.875 ms  50.711 ms  53.082 ms 5  xe-1-1-0-0.lon10.ip.tiscali.net (213.200.78.69)  54.552 ms  62.540 ms  63.025 ms 6  xe-2-0-0.was12.ip.tiscali.net (89.149.185.9)  159.578 ms xe-4-0-0.was12.ip.tiscali.net (89.149.185.13)  138.048 ms xe-2-0-0.was12.ip.tiscali.net (89.149.185.9)  138.784 ms

Not sure where Germany comes into the picture? It looks to me like the last hop above is a router in Washington? A RIPE IP lookup shows that the IP is registered in Germany but that doesn't necessarily mean it's assigned to a machine there.

Quote

Ping-ing the two successive Tiscali routers gives me: From London: $ ping -c 3 213.200.78.69 PING 213.200.78.69 (213.200.78.69) 56(84) bytes of data. 64 bytes from 213.200.78.69: icmp_seq=1 ttl=60 time=28.9 ms 64 bytes from 213.200.78.69: icmp_seq=2 ttl=60 time=44.8 ms 64 bytes from 213.200.78.69: icmp_seq=3 ttl=60 time=22.3 ms --- 213.200.78.69 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 22.352/32.040/44.839/9.440 ms

That looks fine to me.

Quote

From Germany: $ ping -c 3 89.149.185.9 PING 89.149.185.9 (89.149.185.9) 56(84) bytes of data. 64 bytes from 89.149.185.9: icmp_seq=1 ttl=59 time=109 ms 64 bytes from 89.149.185.9: icmp_seq=2 ttl=59 time=106 ms 64 bytes from 89.149.185.9: icmp_seq=3 ttl=59 time=152 ms --- 89.149.185.9 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 106.659/122.818/152.708/21.158 ms

As mentioned above, that router's based in the states from what I can tell. An average ping of 122ms to a US server isn't particularly unusual.

Quote

Same deal coming back from US to UK: 7  pos-0-4-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.26)  28.967 ms  30.171 ms  28.506 ms 8  pos-0-4-0-0-cr01.chicago.il.ibone.comcast.net (68.86.85.165)  45.953 ms  45.803 ms  44.479 ms 9  xe-2-1-0.chi10.ip.tiscali.net (77.67.68.37)  49.983 ms  51.319 ms  49.974 ms 10  xe-2-0-0.lon20.ip.tiscali.net (89.149.186.85)  143.047 ms  141.404 ms  141.515 ms Hop 8 is in the US, hop 9 in Germany in just over 5ms and then from Germany to the UK takes more than an additional 91ms!

Hop 9 is in Chicago not Germany, so it's taking an additional 91ms to cross the pond which is to be expected really.

Quote from: techguy

That does indeed look nasty Mick and might be something that PN need to take up with Tiscali

It looks normal to me.

Quote from: techguy

I'd imagine PN can only raise a fault if the problem is directly with their connection to Tiscali as opposed to a Tiscali internal routing issue which is why noone from PN has responded (or they could be on the case and waiting for a response from Tiscali)

I don't think we need to raise a fault as I don't think we've got a problem TBH. The OP's pings in general seem quite high mind you, @MickKi - Do you know if interleaving has been switched on for your line?

[#8]

Now you mention it Bob, I've actually never seen a sub 100 millisecond US hop with any ISP I've used so apologies.
I do wish providers would come up with a standardised naming convention for the equipment (though didn't exercise my brain enough to work out what it may mean)

[#9]

Thanks for your response Bob,

Quote from: Bob

Are you using default ports for the SSH connection? If not, you might be falling foul of our traffic management platform. You're asking why Tiscali are dropping packets yet all of your traces show 0% packet loss

Yes, I've noticed that.  I am using non-conventional ports to avoid botnets hammering the servers.  On occasions I have noticed increased delays during peak times between the PN gateway and your next router.  When it gets really busy the connection hangs completely (like tonight).

Quote from: Bob

Quote I tried to troubleshoot it and found out that going from UK to US, Tiscali are more than trebling the delay over a single hop (from London to Germany): 2  lo0-plusnet.pte-ag2.plus.net (195.166.128.72)  39.538 ms  42.419 ms  42.911 ms 3  ge0-0-0-504.pte-gw2.plus.net (84.92.4.90)  43.396 ms  43.893 ms  44.823 ms 4  vl23.thn-gw2.plus.net (212.159.4.20)  46.875 ms  50.711 ms  53.082 ms 5  xe-1-1-0-0.lon10.ip.tiscali.net (213.200.78.69)  54.552 ms  62.540 ms  63.025 ms 6  xe-2-0-0.was12.ip.tiscali.net (89.149.185.9)  159.578 ms xe-4-0-0.was12.ip.tiscali.net (89.149.185.13)  138.048 ms xe-2-0-0.was12.ip.tiscali.net (89.149.185.9)  138.784 ms Not sure where Germany comes into the picture? It looks to me like the last hop above is a router in Washington? A RIPE IP lookup shows that the IP is registered in Germany but that doesn't necessarily mean it's assigned to a machine there.

Right, I thought that I should believe the whois results which report Germany, rather than the arbitrary naming scheme that Tiscali might have chosen.  If as you say the naming of the router is to be taken at face value then the delay may well be related to the distance to the US.  It makes sense.

Quote from: Bob

I don't think we need to raise a fault as I don't think we've got a problem TBH. The OP's pings in general seem quite high mind you, @MickKi - Do you know if interleaving has been switched on for your line?

Interleaving has been switched on I'm afraid.  I fear that my line will fall apart due to the relatively high number of FECs & CRCs if it were to be switched off.
So in conclusion, the latency during peak times is most likely related to the traffic shaping applied by PN, rather than any other routing issues on the way.
Thank you for your help.  I will consider changing ports or . . . or changing ISP! 

[#10]

To be honest Mick, I have used Virgin and Newnet and neither of them provide sub 100 millisecond routing to the US but yes you need to add traffic into the mix.
Depends on the connection capacity too