From henk at ripe.net Thu Feb 17 11:47:37 2005 From: henk at ripe.net (Henk Uijterwaal) Date: Thu, 17 Feb 2005 11:47:37 +0100 Subject: 6NET using TTM data Message-ID: <6.2.0.14.2.20050217114611.02c7ced0@localhost> Dear All, Tim Chown reports that the URL for the deliverable from 6NET is: http://www.6net.org/publications/deliverables/D2.2.4.pdf From page 50 onwards, you see comparisons of IPv4 and IPv6 performance. Enjoy, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) From wilhelm at ripe.net Fri Feb 18 20:54:33 2005 From: wilhelm at ripe.net (Rene Wilhelm) Date: Fri, 18 Feb 2005 20:54:33 +0100 Subject: 6NET using TTM data In-Reply-To: Message from Henk Uijterwaal of "Thu, 17 Feb 2005 11:47:37 +0100." <6.2.0.14.2.20050217114611.02c7ced0@localhost> Message-ID: <200502181954.j1IJsXet001608@birch.ripe.net> Henk wrote: > Tim Chown reports that the URL for the deliverable from 6NET is: > http://www.6net.org/publications/deliverables/D2.2.4.pdf > > From page 50 onwards, you see comparisons of IPv4 and IPv6 performance. Page 51 - 56 show TTM results, "Last 30 days" plots, for the measurements *from* four 6NET sites and IIJ in Japan *to* the University of Southampton All plots show IPv6 to have significantly less delay variation than IPv4. While it's nice to see those results, one has to bear in mind the pattern of IPv6 vs. IPv4 delays for one site (U. of Southampton) is not necesarily representative for end-to-end traffic between all 6NET sites. Other test-boxes may well have different results. Page 55 shows the effects of the bad GPS conditions we had on the box at GRNET. The receiver did see enough sattellites, but due to interference from nearby PTT equipment, it had difficulties delivering a stable time signal to the testbox. About 10 days ago, the antenna has been remounted and stable timing was restored. Page 54 shows a plot with a period of almost exactly 50% packet loss. In cases like that it's always good to verify if one is not looking at effects related to a specific testbox itself, i.e. packets not lost in the network, but somehow not being recorded by the receiving box. First a zoom in with plots-on-demand http://www.ripe.net/cgi-bin/ttm/plots-on-demand?SRC=tt119&DST=tt76&mindelay=0&date_start=20050118&time_start=00%3A00&maxdelay=250&date_end=20050122&time_end=00%3A00&format=gif&ipv=6&plottype=delay&zoomlevel=6&SUBMIT=Submit#plot shows: - start and end times of the problem is not on a day boundary - the loss is not exactly 50% but fluctuates around that value Next check another plot, e.g. tt119 to tt73: http://www.ripe.net/cgi-bin/ttm/plots-on-demand?SRC=tt119&DST=tt76&mindelay=0&date_start=20050118&time_start=00%3A00&maxdelay=250&date_end=20050122&time_end=00%3A00&format=gif&ipv=6&plottype=delay&zoomlevel=6&SUBMIT=Submit#plot It shows the same pattern --> the problem is likely close to tt119 (Hungary) Now look at the collected traceroutes (click on the pointer in the page returned by plots-on-demand): http://www.ripe.net/cgi-bin/ttm/routing?ipv=6;SRC=tt119;DST=tt73;date_start=20050118;date_end=20050122;time_start=00%3A00;time_end=00%3A00 Between jan 18 ~21:00 and jan 21 ~08:00 one sees numerous route flaps, correct traceroutes being alternated by traceroutes where hop 2 and 3 didn't respond. This is real proof the packet loss is a network effect, not a testbox problem. It's also a strong indication the problems were in in hbone.hu, the Hungarian backbone. -- Rene =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rene Wilhelm RIPE Network Coordination Centre Email: wilhelm at ripe.net Test Traffic Measurements Phone: +31 20 535 4417 Amsterdam, the Netherlands Fax: +31 20 535 4445 http://www.ripe.net/ttm/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From henk at ripe.net Wed Feb 23 10:56:58 2005 From: henk at ripe.net (Henk Uijterwaal) Date: Wed, 23 Feb 2005 10:56:58 +0100 Subject: DNSMON to Become Production Level Service from March 2005 Message-ID: <5.2.1.1.2.20050223104631.01aa57b0@mailhost.ripe.net> [Apologies for duplicates] Dear Colleagues, The RIPE NCC DNS Monitoring Service (DNSMON) provides a comprehensive, objective and up-to-date overview of the quality of the service offered by high-level Domain Name System (DNS) servers. It is an active measurement service. It uses our Test Traffic Measurements (TTM) network to provide an up-to-date service overview of certain DNS root and Top-Level Domain (TLD) name servers. An important feature is the ability to view historical data. This allows the rapid analysis of both past and present DNS issues. The service is available through its own website at: http://dnsmon.ripe.net Development of the service started in 2003. During the development phase, we offered the service free of charge to the entire Internet community. This will change on 1 March 2005. On this day, the service will become a regular production service and the following will change: - The RIPE NCC will start to charge a service fee to the administrators of the TLDs using DNSMON. This is a request from the RIPE NCC membership, in order to recover the costs of offering the service. - We will continue to offer the service free of charge to users of the TTM service. - Access to the data on the public website will be delayed by two hours from 4 April 2005. What you should do: 1. If you are the host of a Test Box for the TTM service, you need take no action. Data collection will continue and plots will be available from the website at: http://dnsmon.ripe.net. 2. If you are the administrator of a TLD, we will send you a separate e-mail telling you what steps to take. 3. If you are a member of the public using the data on the DNSMON web site you need take no action. DNSMON measures DNS performance between sites that take part in the TTM service and those where DNS servers are installed. If you are a network operator interested in the performance between your site and the DNS servers, you should consider installing a test box at your site. You can find out more about this at: http://www.ripe.net/ttm In recent months, several users suggested additional features for this service. We have noted all suggestions. As soon as we have finished setting up contracts for this service, we will look at the suggestions and come up with a possible implementation scheme. We will post this on the DNSMON Mailing List. If you have any questions, please reply to this e-mail. Kind regards, Henk Uijterwaal RIPE NCC