Piet.Beertema@MCSUN.EU.NET (08/31/90)
From: Michel Fingerhut Organization: IRCAM, Paris (France) Subject: Internet routing Europe -> USA -> Europe... While trying to find whether we (in France, Europe) could reach a site in Germany (Europe), I got the following route from traceroute: >1 ircam-gw (129.102.0.1) 0 ms 0 ms 0 ms >2 fnet-gw.inria.fr (192.44.64.26) 370 ms 550 ms 480 ms >3 sophia-gw.inria.fr (192.5.60.250) 540 ms 350 ms 290 ms ..... Why this contorted route? Is it cost-effective? That's what I see doing a traceroute to 129.102.0.1: traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 38 byte packets 1 iracs1.ira.uka.de (129.13.1.1) 20 ms 0 ms 0 ms 2 ciscogb5.Informatik.Uni-Dortmund.DE (188.1.132.1) 1020 ms 840 ms 1080 ms 3 Amsterdam.NL.EU.NET (134.222.1.1) 4120 ms * 3800 ms 4 Paris.FR.EU.NET (134.222.2.2) 4340 ms 4900 ms 3760 ms 5 fnet-gw.inria.fr (128.93.36.128) 3880 ms 3740 ms * 6 192.44.64.61 (192.44.64.61) 3980 ms 4960 ms * Arnold Nipper Right, that's what I expected: it's just a technical problem (a gateway not announcing a route). In other words: there was no need to send this problem to an extremely wide-reaching mailing list. Contacting the managers of the first gateway (@inria) could have solved the problem... Anyway, we'll go after it and inform the people involved. Piet
pgross@NRI.RESTON.VA.US ("Phillip G. Gross") (08/31/90)
Arnold, Your 6 hop path is certainly more direct, but notice that it takes almost 5 seconds, while the more convoluted 18 hop path via Princeton and Cornell takes only little more than a second. With that type of difference, I have a better understanding for routes via NSFnet for intra-European traffic. Phill >From: Arnold Nipper --- XLINK <nipper%ira.uka.de@relay.cs.net> > >traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 38 byte packets > 1 iracs1.ira.uka.de (129.13.1.1) 20 ms 0 ms 0 ms > 2 ciscogb5.Informatik.Uni-Dortmund.DE (188.1.132.1) 1020 ms 840 ms 1080 ms > 3 Amsterdam.NL.EU.NET (134.222.1.1) 4120 ms * 3800 ms > 4 Paris.FR.EU.NET (134.222.2.2) 4340 ms 4900 ms 3760 ms > 5 fnet-gw.inria.fr (128.93.36.128) 3880 ms 3740 ms * > 6 192.44.64.61 (192.44.64.61) 3980 ms 4960 ms * >From: Michel Fingerhut >Organization: IRCAM, Paris (France) > >1 ircam-gw (129.102.0.1) 0 ms 0 ms 0 ms >. >. >. >18 iracs1.ira.uka.de (192.54.104.49) 1310 ms 1140 ms 1190 ms
nipper@ira.uka.DE (Arnold Nipper --- XLINK) (09/01/90)
>Hi, > >Many of you may have seen the following on the TCP-IP mailing list. Anyone >have any suggestions or comments? > >Thanks, >Phill >------- Forwarded Message > >Date: 30 Aug 90 09:14:35 GMT >From: Michel Fingerhut <eru!hagbard!sunic!mcsun!inria!ircam!mf@bloom-beacon.mit.edu> >Organization: IRCAM, Paris (France) >Subject: Internet routing Europe -> USA -> Europe... >To: tcp-ip@nic.ddn.mil > >While trying to find whether we (in France, Europe) could reach a site >in Germany (Europe), I got the following route from traceroute: > >1 ircam-gw (129.102.0.1) 0 ms 0 ms 0 ms >2 fnet-gw.inria.fr (192.44.64.26) 370 ms 550 ms 480 ms >3 sophia-gw.inria.fr (192.5.60.250) 540 ms 350 ms 290 ms >4 cisco.atlantic.fr (192.33.170.1) 1430 ms 1160 ms 490 ms >5 wormhole.Princeton.EDU (128.112.128.114) 680 ms 710 ms 410 ms >6 ford-gateway.jvnc.net (130.94.0.66) 480 ms 530 ms * >7 nss.jvnc.net (192.12.211.1) 910 ms 640 ms 650 ms >8 Pittsburgh.PA.NSS.NSF.NET (129.140.69.8) 400 ms 500 ms * >9 Ithaca.NY.NSS.NSF.NET (129.140.74.5) 630 ms 720 ms 760 ms >10 lan.cornell.site.psi.net (192.35.82.1) 790 ms 900 ms 930 ms >11 cornell.syr.pop.psi.net (128.145.30.1) 1100 ms 530 ms * >12 albpop.syr.pop.psi.net (128.145.20.2) 740 ms 760 ms 590 ms >13 albpop.nyc2.pop.psi.net (128.145.80.1) 780 ms 920 ms 830 ms >14 nyc2.nyc1.pop.psi.net (128.145.42.2) 700 ms 500 ms 580 ms >15 * nyc_P.lan.nyc1.pop.psi.net (128.145.213.1) 1410 ms 1090 ms >16 nyc1.cuny.pop.psi.net (128.145.14.1) 790 ms 590 ms 910 ms >17 128.145.254.5 (128.145.254.5) 920 ms 740 ms 710 ms >18 iracs1.ira.uka.de (192.54.104.49) 1310 ms 1140 ms 1190 ms > >I.e.: Paris -> South France -> NJ -> PE -> Ithaca (upst. NY--hi, alma matter!) -> >Syracuse (upst. NY) -> NYC, NY -> ? -> Deutschland > >Why this contorted route? Is it cost-effective? > iThat's what I see doing a traceroute to 129.102.0.1: traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 38 byte packets 1 iracs1.ira.uka.de (129.13.1.1) 20 ms 0 ms 0 ms 2 ciscogb5.Informatik.Uni-Dortmund.DE (188.1.132.1) 1020 ms 840 ms 1080 ms 3 Amsterdam.NL.EU.NET (134.222.1.1) 4120 ms * 3800 ms 4 Paris.FR.EU.NET (134.222.2.2) 4340 ms 4900 ms 3760 ms 5 fnet-gw.inria.fr (128.93.36.128) 3880 ms 3740 ms * 6 192.44.64.61 (192.44.64.61) 3980 ms 4960 ms * Arnold Nipper ******************************************************************************** Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe * +49 721 608 4331 ********************************************************************************
mf@ircam.ircam.fr (Michel Fingerhut) (09/01/90)
Arnold Nipper (XLINK, Karlsruhe, Germany) points a traceroute from his machine to ours that goes (as hoped): Germany -> Holland -> Paris while the one I get (Paris -> Germany) goes through upstate NY. Well, THIS IS BECAUSE THE FRENCH GATEWAY DOES NOT ALLOW ACCESS TO HOLLAND and therefore to the rest of what's connected to it. It's a first to me that the reverse is possible, but as they say in French ca me fait une belle jambe.
emv@math.lsa.umich.edu (Edward Vielmetti) (09/02/90)
In article <9008311421.AA08486@mcsun.EU.net> Piet.Beertema@MCSUN.EU.NET writes:
Right, that's what I expected: it's just a technical problem
(a gateway not announcing a route). In other words: there was
no need to send this problem to an extremely wide-reaching
mailing list. Contacting the managers of the first gateway
(@inria) could have solved the problem...
Anyway, we'll go after it and inform the people involved.
Well, maybe yes, maybe no. I think that discussions of this sort are
extremely interesting, and it is useful to draw the attention of the
international community to such events. This is the first I had heard
of such behavior europe->usa->europe; previously someone saw a
usa->europe->usa hop.
There is an IETF working group (the Topology Engineering Working
Group) which has in the past looked into these things;
intercontinental networks are more and more interesting all the time.
I'm waiting for the first report of usa->europe->japan->australia,
myself.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>dfk@eu.net (Daniel Karrenberg) (09/04/90)
pgross@NRI.RESTON.VA.US ("Phillip G. Gross") writes: >Your 6 hop path is certainly more direct, but notice that it takes almost >5 seconds, while the more convoluted 18 hop path via Princeton and Cornell >takes only little more than a second. With that type of difference, I have >a better understanding for routes via NSFnet for intra-European traffic. >>traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 38 byte packets >> 1 iracs1.ira.uka.de (129.13.1.1) 20 ms 0 ms 0 ms >> 2 ciscogb5.Informatik.Uni-Dortmund.DE (188.1.132.1) 1020 ms 840 ms 1080 ms >> 3 Amsterdam.NL.EU.NET (134.222.1.1) 4120 ms * 3800 ms >> 4 Paris.FR.EU.NET (134.222.2.2) 4340 ms 4900 ms 3760 ms >> 5 fnet-gw.inria.fr (128.93.36.128) 3880 ms 3740 ms * >> 6 192.44.64.61 (192.44.64.61) 3980 ms 4960 ms * Just to get the technical facts straight: The 1s delay on hop 1-2 is due to the German research network WIN which is 64kbit/s X.25. I expect that the WIN conections and interfaces on both iracs1.ira.uka.de and ciscogb5.Informatik.Uni-Dortmund.DE are quite loaded so we are looking at queueing delays here both inside WIN and at the routers connecting to it. The 3s delay on hop 2-3 is due to an "open jaw" situation. Traceroute only reports the *outbound* path the packets take. The way the icmp packets get back to the host running traceroute is not reported. No blame on traceroute, it's hard to do. So although it is tempting to assume that the packets come back the same way they get there this is not necessarily true. In this case Amsterdam.NL.EU.net does not know the "direct" route back to Karlsruhe. So the packets are sent by the default route which ends up on NSFnet which delivers using the "long way": traceroute to 129.13.1.1 (129.13.1.1), 30 hops max, 40 byte packets 1 Amsterdam.NL.EU.net (192.16.202.32) 10 ms 0 ms 0 ms 2 Falls-Church.VA.ALTER.NET (134.222.5.2) 1200 ms 560 ms 310 ms 3 College-Park.MD.ALTER.NET (137.39.11.2) 140 ms 150 ms 220 ms 4 192.80.214.254 (192.80.214.254) 260 ms 360 ms 480 ms 5 Ithaca.NY.NSS.NSF.NET (129.140.74.9) 860 ms 2330 ms 2330 ms 6 lan.cornell.site.psi.net (192.35.82.1) 2940 ms 2090 ms 1910 ms 7 cornell.syr.pop.psi.net (128.145.30.1) 1450 ms 1190 ms 740 ms 8 albpop.syr.pop.psi.net (128.145.20.2) 420 ms 390 ms 350 ms 9 albpop.nyc2.pop.psi.net (128.145.80.1) 730 ms 470 ms 850 ms 10 nyc2.nyc1.pop.psi.net (128.145.42.2) 510 ms 200 ms 220 ms 11 nyc_P.lan.nyc1.pop.psi.net (128.145.213.1) 500 ms 370 ms 670 ms 12 nyc1.cuny.pop.psi.net (128.145.14.1) 760 ms 400 ms 710 ms 13 128.145.254.5 (128.145.254.5) 800 ms 390 ms 770 ms 14 * iracs1.ira.uka.de (192.54.104.49) 6810 ms 6760 ms As you can see round trip delays on this route are highly variable. The bottleneck is certainly hop 13-14 which is 19.2 kbit/s at this point. The "faster" traceroute on that route shown earlier in the discussion has just hit the other extreme of the distribution. So far the facts, now the reasons: We are working on the European connectivity problem that this case shows. Since we don't have a pan-European agency wise enough to fund a European equivalent of NSFnet this takes local funding arrangements and they take time. Beleive me we are working hard on this. -- Daniel Karrenberg Future Net: <dfk@cwi.nl> CWI, Amsterdam Oldie Net: mcsun!dfk The Netherlands Because It's There Net: DFK@MCVAX
J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) (09/05/90)
>I'm waiting for the first report of usa->europe->japan->australia, >myself. we have a visitor from crete/greece here at the moment - as i type, he is reading his e-mail on a machine in Heraklion. the traffic from london is routed via princeton... it's still all pony express stuff though... jon