6NET using TTM data

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/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=