...
Les will also send Luiza information on how PingER data has been used.
UM
Badrul (6/23/2014) is still awaiting hearing from his student (Abdulrahim Haroun Ali who is out of the country) on the paper on anomalies in PingER measurements and will update later once the paper ready. For the minute the paper is not ready.
The ping server at http://pinger.fsktm.um.edu.my/cgi-bin/traceroute.pl?target=www.slac.stanford.edu&function=ping gives ping server busy at the moment. Please try again later. Some one with access to the web servers should look at that (e.g. review the web logs). Maybe it is being hit with a lot of requests simultaneously. If they are coming from SLAC we may want to look at reflector.cgi.
Badrul (6/23/2014) is still awaiting hearing from his student (Abdulrahim Haroun Ali who is out of the country) on the paper on anomalies in PingER measurements and will update later once the paper ready. For the minute the paper is not ready.
Ridzuan has put together a rough proposal to use Hadoop to store and make available PingER data. He has registered for the Myren cloud services last month. But until now still not getting any approval for the use of the mentioned services. Will follow up again with them. For the Hadoop implementation, He is considering the use of Hortonworks Hadoop Data (HDP2) platform, however there are some problems with the latest installation because UM adopted IPV6. Most of the HDP2 repositories are resided in IPV4 server thus make it difficult to correctly install to our server. He is trying to Ridzuan has put together a rough proposal to use Hadoop to store and make available PingER data. He has registered for the Myren cloud services last month. But until now still not getting any approval for the use of the mentioned services. Will follow up again with them. For the Hadoop implementation, He is considering the use of Hortonworks Hadoop Data (HDP2) platform, however there are some problems with the latest installation because UM adopted IPV6. Most of the HDP2 repositories are resided in IPV4 server thus make it difficult to correctly install to our server. He is trying to use another platform or find a way to solve this installation problem.
...
The tool to enable synchronizing Malaysian monitors is completed. It has been tested by Saqib. Saqib requested to add sorting the HostList by country, Johari will add this.
The traceroute server at http://pinger2.unimas.my/cgi-bin/traceroute.pl has the same problem as before. They know (sort of) the problem but haven't got the chance to rectify it (mapping NAT address, needs to be added). There is no progress 12/4/2013, 1/8/2013, 1.22.2014, 2/5/2014, 3/26/2014, 4/8/2014, 4/23/2014, 6/4/2014. Now that the historical traceroutes are working for UM (see below) there is an extra incentive to get the reverse traceroute working at UTM and UNIMAS
...
to add sorting the HostList by country, Johari will add this.
The traceroute server at http://pinger2.unimas.my/cgi-bin/traceroute.pl has the same problem as before. They know (sort of) the problem but haven't got the chance to rectify it (mapping NAT address, needs to be added). There is no progress 12/4/2013, 1/8/2013, 1.22.2014, 2/5/2014, 3/26/2014, 4/8/2014, 4/23/2014, 6/4/2014.
...
Johari has a research student who finalized a proposal in order to officially apply for his masters. He will start in February. He is currently working on threshold/anomaly detection, and will extend to correlating performance over multiple routes. He will share the proposal with Les and others April. No progress 6/4/2014.
UTM
Saqib has talked to MYREN they say the routers at hops 5 and 6 in the traceroute from UM to UNIMAS are both at UM and the long delay between them is due to congestion. I am skeptical since hops 6-12 have similar RTT and 12 is near Kuching. I suggest Saqib run mtr for a day or more from UM to UNIMAS see if there is any day night variation in RTT. If min RTT gets down to <2 ms, then the MYREN guy is right. If it is ~ 50ms and persists for several days then it really does not look like congestion (which should vary day night as the number of users changes). In that case then it really appears hop 6 is physically close to hop 12 since they have the same min RTT. Taken together with the email from UM I would be very suspicious of the MYREN statement.
Saqib met with MYREN who have made many topology changes. Saqib will also incorporate these into the Malaysian case study. He is seeing anomalously long delays between mainland Malaysia and Sarawak. It does not appear to be due to congestion. We need to understand the routing and which undersea cables are being used. Saqib will send more details after the meeting. He will also contact MYREN.
Saqib's proposal is almost ready however we do not see somewhere (funding agency) to submit it to. The next round of the FRGS may be the next opportunity. Anjum and Saqib will discuss where best to fit Saqib's proposal and Anjum will help edit the proposal.
...
Now that the historical traceroutes are working for UM (see below) there is an extra incentive to get the reverse traceroute working at UTM and UNIMAS
Johari has a research student who finalized a proposal in order to officially apply for his masters. He will start in February. He is currently working on threshold/anomaly detection, and will extend to correlating performance over multiple routes. He will share the proposal with Les and others April. No progress 6/4/2014.
UTM
Saqib has talked to MYREN they say the routers at hops 5 and 6 in the traceroute from UM to UNIMAS are both at UM and the long delay between them is due to congestion. I am skeptical since hops 6-12 have similar RTT and 12 is near Kuching. I suggest Saqib run mtr for a day or more from UM to UNIMAS see if there is any day night variation in RTT. If min RTT gets down to <2 ms, then the MYREN guy is right. If it is ~ 50ms and persists for several days then it really does not look like congestion (which should vary day night as the number of users changes). In that case then it really appears hop 6 is physically close to hop 12 since they have the same min RTT. Taken together with the email from UM I would be very suspicious of the MYREN statement.
Saqib met with MYREN who have made many topology changes. Saqib will also incorporate these into the Malaysian case study. He is seeing anomalously long delays between mainland Malaysia and Sarawak. It does not appear to be due to congestion. We need to understand the routing and which undersea cables are being used. Saqib will send more details after the meeting. He will also contact MYREN.
Saqib's proposal was submitted his proposal to FRGS. He received a requested revision. Anjum was going to help edit the proposal
...
.
Saqib also reports there is a change in traceroute from SLAC to UNIMAS in this month. Previously, it goes via TEIN3. Further, it did not touch the MYREN network.
...