3

my name is Abdulla and I'm from Kuwait. Sorry for my question as I know its not technically challenging.

I'm facing some problems with my internet connection. My company has a DSL 2mb connection. My main problem is latency, in the morning its good but after that its gets really bad. My Internet provider says there's nothing wrong and that everything is working perfectly. I tried to explain to them the latency issue but they say that as long as I'm getting the download speed there isn't anything I can do about it.

I only want to know if this is true and that the company can't do anything before I change my internet provider, as I feel that the guys at the contact center might getting back to me without asking tech support.

Below are 2 traces I made, one in the morning and the other in the afternoon:

This was taken around 17:00

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrator>ping google.com


Pinging google.com [66.102.9.104] with 32 bytes of data:


Reply from 66.102.9.104: bytes=32 time=387ms TTL=49

Reply from 66.102.9.104: bytes=32 time=388ms TTL=49

Reply from 66.102.9.104: bytes=32 time=375ms TTL=49

Reply from 66.102.9.104: bytes=32 time=375ms TTL=49


Ping statistics for 66.102.9.104:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 375ms, Maximum = 388ms, Average = 381ms


C:\Documents and Settings\Administrator>ping google.com /t


Pinging google.com [66.102.9.104] with 32 bytes of data:


Reply from 66.102.9.104: bytes=32 time=376ms TTL=49

Reply from 66.102.9.104: bytes=32 time=382ms TTL=49

Reply from 66.102.9.104: bytes=32 time=371ms TTL=49

Reply from 66.102.9.104: bytes=32 time=378ms TTL=49

Reply from 66.102.9.104: bytes=32 time=374ms TTL=49

Reply from 66.102.9.104: bytes=32 time=371ms TTL=49

Reply from 66.102.9.104: bytes=32 time=365ms TTL=49

Reply from 66.102.9.104: bytes=32 time=366ms TTL=49

Reply from 66.102.9.104: bytes=32 time=353ms TTL=49

Reply from 66.102.9.104: bytes=32 time=331ms TTL=49

Reply from 66.102.9.104: bytes=32 time=333ms TTL=49

Reply from 66.102.9.104: bytes=32 time=348ms TTL=49

Reply from 66.102.9.104: bytes=32 time=365ms TTL=49

Reply from 66.102.9.104: bytes=32 time=346ms TTL=49

Reply from 66.102.9.104: bytes=32 time=335ms TTL=49

Reply from 66.102.9.104: bytes=32 time=340ms TTL=49

Reply from 66.102.9.104: bytes=32 time=344ms TTL=49

Reply from 66.102.9.104: bytes=32 time=333ms TTL=49

Reply from 66.102.9.104: bytes=32 time=328ms TTL=49

Reply from 66.102.9.104: bytes=32 time=332ms TTL=49

Reply from 66.102.9.104: bytes=32 time=326ms TTL=49

Reply from 66.102.9.104: bytes=32 time=333ms TTL=49

Reply from 66.102.9.104: bytes=32 time=325ms TTL=49

Reply from 66.102.9.104: bytes=32 time=333ms TTL=49

Reply from 66.102.9.104: bytes=32 time=338ms TTL=49

Reply from 66.102.9.104: bytes=32 time=341ms TTL=49


Ping statistics for 66.102.9.104:

    Packets: Sent = 26, Received = 26, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 325ms, Maximum = 382ms, Average = 348ms

Control-C
^C
C:\Documents and Settings\Administrator>travert google.com
'travert' is not recognized as an internal or external command,
operable program or batch file.

C:\Documents and Settings\Administrator>tracert google.com


Tracing route to google.com [66.102.9.104]

over a maximum of 30 hops:


  1    <1 ms    <1 ms    <1 ms  192.168.0.1

  2     6 ms     6 ms     6 ms  80-184-31-1.adsl.kems.net [80.184.31.1]

  3     7 ms     7 ms     8 ms  168.187.0.226

  4     7 ms     8 ms     9 ms  168.187.0.125

  5   180 ms   187 ms   188 ms  if-11-2.core1.RSD-Riyad.as6453.net [116.0.78.89]


  6   209 ms   222 ms   204 ms  195.219.167.57

  7   541 ms   536 ms   540 ms  195.219.167.42

  8   553 ms   552 ms   538 ms  Vlan1102.icore1.PVU-Paris.as6453.net [195.219.24
1.109]

  9   547 ms   543 ms   542 ms  xe-9-1-0.edge4.paris1.level3.net [4.68.110.213]


 10   540 ms   523 ms   531 ms  ae-33-51.ebr1.Paris1.Level3.net [4.69.139.193]

 11   755 ms   761 ms   695 ms  ae-45-45.ebr1.London1.Level3.net [4.69.143.101]


 12   271 ms   263 ms   400 ms  ae-11-51.car1.London1.Level3.net [4.69.139.66]

 13   701 ms   730 ms   742 ms  195.50.118.210

 14   659 ms   641 ms   660 ms  209.85.255.76

 15   280 ms   283 ms   292 ms  209.85.251.190

 16   308 ms   293 ms   296 ms  72.14.232.239

 17   679 ms   700 ms   721 ms  64.233.174.18

 18   268 ms   281 ms   269 ms  lm-in-f104.1e100.net [66.102.9.104]


Trace complete.

C:\Documents and Settings\Administrator>

This was taken at 10:00am

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Administrator>ping google.com

Pinging google.com [66.102.9.106] with 32 bytes of data:

Reply from 66.102.9.106: bytes=32 time=110ms TTL=49

Reply from 66.102.9.106: bytes=32 time=111ms TTL=49

Reply from 66.102.9.106: bytes=32 time=112ms TTL=49

Reply from 66.102.9.106: bytes=32 time=120ms TTL=49

Ping statistics for 66.102.9.106:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 110ms, Maximum = 120ms, Average = 113ms

C:\Documents and Settings\Administrator>ping google.com /t

Pinging google.com [66.102.9.106] with 32 bytes of data:

Reply from 66.102.9.106: bytes=32 time=109ms TTL=49

Reply from 66.102.9.106: bytes=32 time=110ms TTL=49

Reply from 66.102.9.106: bytes=32 time=111ms TTL=49

Reply from 66.102.9.106: bytes=32 time=111ms TTL=49

Reply from 66.102.9.106: bytes=32 time=112ms TTL=49

Reply from 66.102.9.106: bytes=32 time=112ms TTL=49

Reply from 66.102.9.106: bytes=32 time=116ms TTL=49

Reply from 66.102.9.106: bytes=32 time=110ms TTL=49

Reply from 66.102.9.106: bytes=32 time=109ms TTL=49

Reply from 66.102.9.106: bytes=32 time=110ms TTL=49

Reply from 66.102.9.106: bytes=32 time=109ms TTL=49

Reply from 66.102.9.106: bytes=32 time=110ms TTL=49

Reply from 66.102.9.106: bytes=32 time=112ms TTL=49

Reply from 66.102.9.106: bytes=32 time=109ms TTL=49

Reply from 66.102.9.106: bytes=32 time=110ms TTL=49

Reply from 66.102.9.106: bytes=32 time=115ms TTL=49

Reply from 66.102.9.106: bytes=32 time=110ms TTL=49

Reply from 66.102.9.106: bytes=32 time=109ms TTL=49

Reply from 66.102.9.106: bytes=32 time=110ms TTL=49

Reply from 66.102.9.106: bytes=32 time=113ms TTL=49

Reply from 66.102.9.106: bytes=32 time=115ms TTL=49

Reply from 66.102.9.106: bytes=32 time=109ms TTL=49

Reply from 66.102.9.106: bytes=32 time=110ms TTL=49

Ping statistics for 66.102.9.106:

    Packets: Sent = 32, Received = 32, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 109ms, Maximum = 135ms, Average = 112ms

Control-C
^C
C:\Documents and Settings\Administrator>tracert google.com

Tracing route to google.com [66.102.9.104]

over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1

  2     6 ms     6 ms     6 ms  80-184-31-1.adsl.kems.net [80.184.31.1]

  3     8 ms     7 ms     6 ms  168.187.0.226

  4     6 ms     7 ms     7 ms  168.187.0.125

  5    20 ms    20 ms    18 ms  if-11-2.core1.RSD-Riyad.as6453.net [116.0.78.89]

  6   171 ms   205 ms   215 ms  195.219.167.57

  7   191 ms   215 ms   226 ms  195.219.167.42

  8     *      103 ms    94 ms  Vlan1102.icore1.PVU-Paris.as6453.net [195.219.24
1.109]

  9    94 ms    95 ms    97 ms  xe-9-1-0.edge4.paris1.level3.net [4.68.110.213]

 10    94 ms    94 ms    94 ms  ae-33-51.ebr1.Paris1.Level3.net [4.69.139.193]

 11   101 ms   101 ms   101 ms  ae-48-48.ebr1.London1.Level3.net [4.69.143.113]

 12   102 ms   102 ms   101 ms  ae-11-51.car1.London1.Level3.net [4.69.139.66]

 13   103 ms   102 ms   103 ms  195.50.118.210

 14   137 ms   103 ms   100 ms  209.85.255.76

 15   130 ms   124 ms   124 ms  209.85.251.190

 16   114 ms   116 ms   116 ms  72.14.232.239

 17   135 ms   113 ms   126 ms  64.233.174.18

 18   126 ms   125 ms   127 ms  lm-in-f104.1e100.net [66.102.9.104]

Trace complete.

C:\Documents and Settings\Administrator>

2 Answers 2

3

Okay, well it looks to me like the latency comes in with the TATA communications network. So your provider KEMS Peers only with TATA communications.

If another ISP peers with a different provider in your area (Kuwait?) then maybe you will get better performance. If the other ISPs still peer with TATA it looks like you won't do any better with them unless they have higher priority on TATA's network.

You can find this out by using whois to see who owns which IP:

$ whois 168.187.0.226

...
inetnum:        168.187.0.0 - 168.187.255.255
netname:        KEMS-KW
org:            ORG-GI9-RIPE
descr:          Kuwait Electronic and Messaging Services Company
descr:          PO Box No 31811111
descr:          Safat, kw 13036
country:        KW
...

You can then run a BGP peering query against that AS:

whois -h v4-peer.whois.cymru.com 168.187.0.226
PEER_AS | IP               | AS Name
6453    | 168.187.0.226    | GLOBEINTERNET TATA Communications

So looking at the latency it ends up being within the TATA communications network if I am reading it correctly.

As a disclaimer, I have never worked for an ISP, so someone who has might be more authoritative than my answer.

1
  • Thank you for being kind enough to help, now that we put this out of the way :) all I can say is wOW you're the best, I can't believe how you broke it down to the main cause of the problem. Thank you so much.
    – Abdulla
    May 1, 2010 at 19:20
2

Kyle is basically right. The latency problem appears to be upstream from your ISP, so there's little they can do about it directly, since the problem isn't in their own network.

At 17:00, you had:

5   180 ms   187 ms   188 ms  if-11-2.core1.RSD-Riyad.as6453.net [116.0.78.89]
6   209 ms   222 ms   204 ms  195.219.167.57
7   541 ms   536 ms   540 ms  195.219.167.42
8   553 ms   552 ms   538 ms  Vlan1102.icore1.PVU-Paris.as6453.net [195.219.241.109]

At 10:00, you had:

5    20 ms    20 ms    18 ms  if-11-2.core1.RSD-Riyad.as6453.net [116.0.78.89]
6   171 ms   205 ms   215 ms  195.219.167.57
7   191 ms   215 ms   226 ms  195.219.167.42
8     *      103 ms    94 ms  Vlan1102.icore1.PVU-Paris.as6453.net [195.219.241.109]

See the change in latency between 195.219.167.57 and 195.219.167.42? In the morning, it's only about 10 ms, which is fine. However, in the afternoon, there's a 300 ms difference. Both are part of TATA's backbone network, and your trace (and general comments) seem to indicate that TATA experiences congestion between those two IPs during the afternoon. In short, they have too much traffic going though a link with insufficient bandwidth.

Kyle is right. Since the problem is in TATA's network, it's their problem to fix. Your ISP appears to use TATA as an uplink. I can think of three choices available to you:

  • Pressure your ISP to put pressure on TATA to fix the problem. This will unfortunately probably not be much help, but if enough people complain about the problem, they might do something about it. TATA might already have plans to fix it, and you might never know if your ISP doesn't contact TATA.
  • Find out if your ISP has other Internet uplinks. If so, find out if it's possible for them to reroute your traffic away from TATA's network.
  • Find another ISP that does not use TATA's network, or at least one that uses TATA but does not route through this congestion point.
1
  • I really thank you for your help, because of you now I understand the problem (and the alternative solutions). I will sure contact them again, but this time I will talk to the tech support and not the Call Center.
    – Abdulla
    May 1, 2010 at 19:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .