Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!dfk From: dfk@eu.net (Daniel Karrenberg) Newsgroups: comp.protocols.tcp-ip Subject: Re: Long lines... Message-ID: <1792@mcsun.eu.net> Date: 4 Sep 90 10:33:19 GMT References: <9008311031.aa04635@NRI.NRI.Reston.VA.US> Organization: European Unix systems User Group Lines: 67 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: CWI, Amsterdam Oldie Net: mcsun!dfk The Netherlands Because It's There Net: DFK@MCVAX