 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30/01/14 01:43, Francois Labreque wrote:
>
> See for example, tracerouting from my home PC to the Indian govt web site.
>
> C:\Documents and Settings\Francois>tracert india.gov.in
>
> Tracing route to india.gov.in [164.100.129.97]
> over a maximum of 30 hops:
>
> 1 <1 ms <1 ms <1 ms 192.168.1.1
> 2 8 ms 10 ms 17 ms 10.21.136.1
> 3 16 ms 12 ms 10 ms 216.113.124.170
> 4 22 ms 27 ms 23 ms 216.113.123.249
> 5 20 ms 21 ms 32 ms eqix-ny9.bhartiairtel.com [198.32.118.170]
> 6 292 ms 295 ms 295 ms 182.79.255.249
> 7 302 ms 295 ms 293 ms
> ABTS-North-Static-218.176.144.59.airtelbroadband
> ..in [59.144.176.218]
> 8 * * * Request timed out.
> 9 * * * Request timed out.
> 10 * ^C
> C:\Documents and Settings\Francois>
>
An interesting experiment. From my machine (UK based) I get:
aphrodite:/home/john # traceroute -m 50 india.gov.in
traceroute to india.gov.in (164.100.129.97), 50 hops max, 60 byte packets
1 BThomehub.home (192.168.1.254) 2.084 ms 2.978 ms 3.046 ms
2 217.32.146.161 (217.32.146.161) 22.737 ms 24.163 ms 24.778 ms
3 217.32.146.190 (217.32.146.190) 26.508 ms 26.588 ms 27.874 ms
4 217.32.147.218 (217.32.147.218) 29.319 ms 29.922 ms 30.652 ms
5 213.120.178.69 (213.120.178.69) 32.326 ms 35.687 ms 36.942 ms
6 217.41.168.109 (217.41.168.109) 37.880 ms 22.664 ms 23.369 ms
7 109.159.249.236 (109.159.249.236) 24.668 ms 109.159.249.238
(109.159.249.238) 22.990 ms acc2-10GigE-0-2-0-7.l-far.21cn-ipp.bt.net
(109.159.249.231) 24.066 ms
8 core1-te0-7-0-17.faraday.ukcore.bt.net (109.159.249.141) 27.245 ms
core1-te0-7-0-15.faraday.ukcore.bt.net (109.159.249.165) 27.899 ms
core2-te0-15-0-6.faraday.ukcore.bt.net (109.159.249.161) 31.393 ms
9 peer2-xe8-0-1.telehouse.ukcore.bt.net (109.159.254.179) 27.944 ms
host213-121-193-131.ukcore.bt.net (213.121.193.131) 28.547 ms 29.640 ms
10 166-49-211-184.eu.bt.net (166.49.211.184) 30.404 ms
t2c3-xe-0-1-3-0.uk-lon1.eu.bt.net (166.49.211.168) 31.310 ms
166-49-211-196.eu.bt.net (166.49.211.196) 22.549 ms
11 linx1.teleglobe.net (195.66.224.51) 50.413 ms 50.465 ms 50.788 ms
12 if-26-2.tcore2.LDN-London.as6453.net (80.231.62.57) 56.706 ms
57.295 ms 53.750 ms
13 if-15-2.tcore2.L78-London.as6453.net (80.231.131.117) 52.537 ms *
53.601 ms
14 if-9-2.tcore2.WYN-Marseille.as6453.net (80.231.200.13) 54.922 ms
56.086 ms 56.757 ms
15 * 80.231.200.26 (80.231.200.26) 154.565 ms 155.180 ms
16 * * *
17 14.140.113.30.static-Delhi-vsnl.net.in (14.140.113.30) 174.327 ms
176.294 ms 175.233 ms
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *
34 * * *
35 * * *
36 * * *
37 * * *
38 * * *
39 * * *
40 * * *
41 * * *
42 * * *
43 * * *
44 * * *
45 * * *
46 * * *
47 * * *
48 * * *
49 * * *
50 * * *
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
But to Japan I get:
aphrodite:/home/john # traceroute -m 50 www.mofa.go.jp
traceroute to www.mofa.go.jp (213.123.84.48), 50 hops max, 60 byte packets
1 BThomehub.home (192.168.1.254) 1.686 ms 2.504 ms 2.648 ms
2 217.32.146.161 (217.32.146.161) 23.864 ms 24.527 ms 25.340 ms
3 217.32.146.206 (217.32.146.206) 26.355 ms 28.282 ms 28.443 ms
4 217.32.147.226 (217.32.147.226) 30.669 ms 30.921 ms 31.532 ms
5 213.120.178.69 (213.120.178.69) 32.794 ms 34.308 ms 34.983 ms
6 217.41.168.109 (217.41.168.109) 36.644 ms 22.228 ms 22.540 ms
7 31.55.162.69 (31.55.162.69) 23.263 ms 24.171 ms 25.002 ms
8 213.123.84.48 (213.123.84.48) 25.734 ms 26.117 ms 27.255 ms
I think this says more about Indian infrastructure than anything else.
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> That's one sloooooow connection - luckily nowadays "the cloud" is a lot
>> faster, IME companies specialising in that type of engineering
>> outsourcing work usually have very fast connections (they would have
>> received a 20MB file before you could call them and say "hello").
>
> 200ms from North America to India is extremely fast.
I'm talking about your transfer rate of 20MB in 6 hours being slow. I
have a 143 ms ping here to www.microsoft.com but can download at over a
megabyte per second. How are the two linked? If your link took 6 hours
to download 20MB then it wasn't because of the ping being 200ms.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> But to Japan I get:
>
> aphrodite:/home/john # traceroute -m 50 www.mofa.go.jp
> traceroute to www.mofa.go.jp (213.123.84.48), 50 hops max, 60 byte packets
> 1 BThomehub.home (192.168.1.254) 1.686 ms 2.504 ms 2.648 ms
> 2 217.32.146.161 (217.32.146.161) 23.864 ms 24.527 ms 25.340 ms
> 3 217.32.146.206 (217.32.146.206) 26.355 ms 28.282 ms 28.443 ms
> 4 217.32.147.226 (217.32.147.226) 30.669 ms 30.921 ms 31.532 ms
> 5 213.120.178.69 (213.120.178.69) 32.794 ms 34.308 ms 34.983 ms
> 6 217.41.168.109 (217.41.168.109) 36.644 ms 22.228 ms 22.540 ms
> 7 31.55.162.69 (31.55.162.69) 23.263 ms 24.171 ms 25.002 ms
> 8 213.123.84.48 (213.123.84.48) 25.734 ms 26.117 ms 27.255 ms
>
> I think this says more about Indian infrastructure than anything else.
>
> John
>
I think your ISP is playing tricks on you. At least mine is being
honest about it...
C:\Documents and Settings\Francois>tracert www.mofa.go.jp
Tracing route to a122.dscksd.akamai.net [24.200.239.194]
over a maximum of 30 hops:
1 <1 ms <1 ms 15 ms 192.168.1.1
2 8 ms 9 ms 8 ms 10.21.136.1
3 10 ms 12 ms 15 ms 216.113.124.157
4 10 ms 10 ms 9 ms cache.google.com [24.200.239.194]
Trace complete.
C:\Documents and Settings\Francois>
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> That's one sloooooow connection - luckily nowadays "the cloud" is a lot
>>> faster, IME companies specialising in that type of engineering
>>> outsourcing work usually have very fast connections (they would have
>>> received a 20MB file before you could call them and say "hello").
>>
>> 200ms from North America to India is extremely fast.
>
> I'm talking about your transfer rate of 20MB in 6 hours being slow. I
> have a 143 ms ping here to www.microsoft.com but can download at over a
> megabyte per second. How are the two linked? If your link took 6 hours
> to download 20MB then it wasn't because of the ping being 200ms.
I suspect that Microsoft will have servers in the UK to send files to
faster than if you were getting them from Redmond.
Secondly, I never claimed that the network latency was the only reason
for the length of the transfer, but it is definitely one of the main
reasons.
This is how it goes (let's assume a well behaved protocol, like FTP):
Every ten packets or so, the sender has to wait for the recipient to
acknoledge reception of the packets,
Server sends 10 packets...
... it takes 200ms for them to get there.
Client acknowledges...
... it takes 200ms for the acknowlegdement to get back.
Server send 10 more packets...
etc...
Now, as Dr. John said in another e-mail, we have to take into account
the quality of the Indian telecommunications infrastructure, so let's
say that 1 packet out of 20 gets dropped, sometimes the scenario becomes:
Server sends 10 packets...
... it takes 200ms for them to get there, but packet #4 got dropped.
Client acknowledges reception of the first 3... packets 5-10 are ignored.
... it takes 200ms for the acknowlegdement to get back.
Server re-sends packets 4-10 and sends 11-13...
etc...
Now, remember that there are supposed to be multiple persons in India
trying to load different files at the same time, so on top of the
retransmissions due to poor line quality, you also run the risk of
having congestions, causing delays in transmission, which will make the
server assume that none of the packets were received, since they weren't
acknoleged on time, causing them to be resent, causing further congestion.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Server sends 10 packets...
> ... it takes 200ms for them to get there, but packet #4 got dropped.
> Client acknowledges reception of the first 3... packets 5-10 are ignored.
> ... it takes 200ms for the acknowlegdement to get back.
> Server re-sends packets 4-10 and sends 11-13...
> etc...
LOL if anyone wrote a protocol to work like that they should be shot!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Server sends 10 packets...
>> ... it takes 200ms for them to get there, but packet #4 got dropped.
>> Client acknowledges reception of the first 3... packets 5-10 are ignored.
>> ... it takes 200ms for the acknowlegdement to get back.
>> Server re-sends packets 4-10 and sends 11-13...
>> etc...
>
> LOL if anyone wrote a protocol to work like that they should be shot!
>
You mean like this?
http://www.rfc-editor.org/rfc/rfc793.txt
http://www.rfc-editor.org/rfc/rfc813.txt
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Server sends 10 packets...
>>> ... it takes 200ms for them to get there, but packet #4 got dropped.
>>> Client acknowledges reception of the first 3... packets 5-10 are
>>> ignored.
>>> ... it takes 200ms for the acknowlegdement to get back.
>>> Server re-sends packets 4-10 and sends 11-13...
>>> etc...
>>
>> LOL if anyone wrote a protocol to work like that they should be shot!
>>
> You mean like this?
>
> http://www.rfc-editor.org/rfc/rfc793.txt
> http://www.rfc-editor.org/rfc/rfc813.txt
>
>
Forgot to add: Johnathan Postel - who wrote most of the early IETF RFCs
- is already dead, so you can't shoot him.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> You mean like this?
>>
>> http://www.rfc-editor.org/rfc/rfc793.txt
>> http://www.rfc-editor.org/rfc/rfc813.txt
I guess back then we didn't imagine it would be completely normal to
transfer gigabytes of data around the world at hundreds of megabits per
second.
> Forgot to add: Johnathan Postel - who wrote most of the early IETF RFCs
> - is already dead, so you can't shoot him.
Good job RFC-2018 was written then to fix the exact problem you highlighted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> You mean like this?
>>>
>>> http://www.rfc-editor.org/rfc/rfc793.txt
>>> http://www.rfc-editor.org/rfc/rfc813.txt
>
> I guess back then we didn't imagine it would be completely normal to
> transfer gigabytes of data around the world at hundreds of megabits per
> second.
>
>> Forgot to add: Johnathan Postel - who wrote most of the early IETF RFCs
>> - is already dead, so you can't shoot him.
>
> Good job RFC-2018 was written then to fix the exact problem you
> highlighted.
>
And Cisco load balancers clear those options, by default. (And guess
what kinds of problems I've been troubleshooting for the last few months?)
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/security/guide/tcpipnrm.html#wp1010795
I guess that's one reason why they're running out of that business!
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
