Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

? Individual emails sent

Actual Attendees

Wajahat, Saqib, Johari, Charnsak, Les, Bebo, Umar

Saqib had problems with his connection and was able to hear but not be heard.

Others

Administration

...

  • We are unable to gather data from the Amity MA, or even ping it, emails sent May 28th and June 3rd, 2018, June 30.
  • The Android version of the PingER MA 
    • email sent June 5th and again June 30th:
      • Now that you have support for regularly updating the Beacons, one of the next things is to think about is how to get the data to the repository/archive (SLAC).
        A possibility is outlined in https://confluence.slac.stanford.edu/display/IEPM/Proxy+support+for+PingER.  Perhaps your team might be interested in pursuing step 1.  If necessary we could also think about providing an account at SLAC to enable a student to work on step 2.
      • The students have gone on the summer break, they will be back by the 2nd week in July.

Thailand (Updated

...

7/

...

5/2018)

For his IPv6 monitoring Charnsak is using ~ 100 IPv6 targets from Saqib. They are in the <HostList> of the Ubra PingER MA. It can be seen from http://www-wanmon.slac.stanford.edu/cgi-wrap/pingtable.pl?file=average_rtt&by=by-node&size=100&tick=monthly&from=TH.UBRU.CS.AC.PINGER6&to=WORLD&ex=none&only=all&ipv=all&dataset=hep&percentage=any. It is still running smoothly. However, we are only seeing about 16 nodes in the report.  There may be a bug somewhere or maybe the hosts need to be entered into NODEDETAILS meta database of hosts.

Charnsak is looking at a host in Champasak University, Chan Parsa province in Laos as a potential site for a PingER MA. Charnsak just got approved to make contact with the Champasak University. He expects to set up the MA in the next 4-5 months (say towards end 2018). It also depends on the partner university, and there may be a lot of paperwork.

...

monitoring site pinger6.ubru.cs.ac.th Charnsak has a pinger.xml configuration file with over 160 IPv6 targets. However, there is a huge discrepancy since there are only about 13 targets responding. We need to get the latest pinger2.pl measurement agent script installed so we can get better logging and see why the other hosts are not being monitored. Les and  Charnsak are working on this..

Charnsak is looking at a host in Champasak University, Chan Parsa province in Laos as a potential site for a PingER MA. Charnsak just got approved to make contact with the Champasak University. He expects to set up the MA in the next 4-5 months (say towards end 2018). It also depends on the partner university, and there may be a lot of paperwork.

UNIMAS (updated 7/5/2018)

Need to add Umar Kalim http://pinger.unimas.my/pinger/contact.php. Johari can't ssh into the server so he will go to it on Monday.  He will also upload the new UNIMAS PingER website next week.

UUM (Updated 7/5/2018)

Les has sent Adib updates to Figs 3, 4, 5 to extend out to 2018. This is for the paper  Socio-economic Development Indices and Their Reflection on Internet Performance in ASEAN Countries

Adib will submit the paper to World Developmenthttps://www.journals.elsevier.com/world-development

NUST: (Updated 7/5/3/2018))

No intern has joined Wajahat's Lab. So there is not much progress. The students are away on summer vacation so no progress.

 

Wajahat proposes to get a list of the new Universities in Pakistan and contact them encouraging them to participate in PingER and set up MA. They have made a list of new university sites, communications networks, Labs in different regions of Pakistan (especially the remote regions) and will make contact.

  • The list of new universities is ready. Just need resources to engage them. 
  • Unsure how this is affected by lack of interns.

Discussion item:

Wajahat is hoping to get few students to work on Master thesis related to pinger data. If possible kindly share ideas related to data analytics which he can share with students

Suggestions anyone?

 Wajahat also asked last time:

  •  “Has any work gone into to predicting the cause of failures(blackout, flood, coup (Turkey)) using pinger data?”
  • Les> there have been several case studies looking at the impacts of failures, however nothing on predicting failures. I am not sure how one might use PinGER to predict the cause of a failure. For some cases (e.g. earthquakes, tsunamis, flood, coup), it is unclear to me how Network performance monitoring could add to other means of predicting the cause.
  • Wajahat's thinking is along the lines of "Regarding other sources, I was thinking, internet is the pulse of digital world. Other sources require additional setup that might not be a possibility in developing countries. Internet being a necessity and having other uses is still prevalent in these developing countries. Can it be used as a real time sensor."
  • Again I am forwarding the question in case others in the team may have some suggestions?  Below are some responses:
    • Umar mentioned the use of dark fibre testing (e.g strain) and monitoring for earthquakes. There was a recent paper.
  • Umar was thinking that using the PingER data to detect and log anomalies and create alerts might be interesting.  This would include triaging the logs into 3 tiers of alerts:
    • Low = Information; 
    • Medium = needs action but non-critical, create a ticket to be looked at later; 
    • Severe: e.g. wake someone up.
  •  It requires hysteresis so one does not get continuous alerts for say something that has gone down. 
  • . Internet being a necessity and having other uses is still prevalent in these developing countries. Can it be used as a real time sensor."
  • Again I am forwarding the question in case others in the team may have some suggestions?  Below are some responses:
    • Umar mentioned the use of dark fibre testing (e.g strain) and monitoring for earthquakes. There was a recent paper.
  • Umar was thinking that using the PingER data to detect and log anomalies and create alerts might be interesting.  This would include triaging the logs into 3 tiers of alerts:
    • Low = Information; 
    • Medium = needs action but non-critical, create a ticket to be looked at later; 
    • Severe: e.g. wake someone up.
  •  It requires hysteresis so one does not get continuous alerts for say something that has gone down. 
  • This makes a lot of sense for say routers and switches which are usually very critical. 
  • The PingER measurement script (pinger2.pl) has a lot of logs that are prioritized by severity (e.g. target not responding for various reasons for the last n runs of pinger2.pl
  • Tiering of events into alert levels would be the focus of the research
  • PingER might be an interesting field to try out the marshaling of event and categorizing into alert levels/tiering. 
  • Possibly mine the data with say Splunk. Umar looked at this: Splunk would be useful for rudimentary for simple scenarios, but not for detailed work.
  • Might be an interesting project for an MS or PhD student.This makes a lot of sense for say routers and switches which are usually very critical. 
  • For PingER it might include correlation with feeds from elsewhere (e.g. earthquakes, tsunamis, social unrest)
  • The PingER measurement script (pinger2.pl) has a lot of logs that are prioritized by severity (e.g. target not responding for various reasons for the last n runs of pinger2.pl. 
  • Possibly mine the data with say Splunk.
  • Might be an interesting project for a student.
  • Prediction/tracking:
    • For unexpected events such as earthquakes/tsunamis, it is doubtful PingER data would be useful for predictions
    • For situations that are developing such as hurricanes, civil unrest: knowing roughly where it is developing might make it possible to temporarily increase the density of targets in the region. To do this would mean having a lot more targets available worldwide ready to be monitored.
      • One would need to be careful to ensure that the extra monitoring does not interfere with Internet access in the area.
    • This tracking might be very valuable for less developed areas where there may be few other (non-PingER) measurements available. However, it can be hard to find the coordinates of ping responding targets is such areas. This would need to be one of the tools developed.
    Any further thoughts this month?
 
SLAC was unable to gather data from:
  • 121.52.146.180 (kohat.edu.pk) down since Nov 22/2017. Wajahat recommends continuing at least until the new student is up to speed (3/8/2018). No data available 3/24/2018.
  • cae.seecs.edu.pk last time we were able to gather any data was February 27th.
  • pinger-ncp.ncp.edu.pk pings but can't gather data 8/11/2017 and 9/16/2017. Contacted. Pings but can't gather data 10/24/2017. They are in the process of restoring 1/17/2018. Still down February 28, 2018, await new student. (3/8/2018). No data 3/24/2018.
  • pinger.isra.edu.pk unable to gather data since 3/6/2018, also does not ping.
  • Wajahat says they will get these nodes up. These have been good nodes. They just need the weekly push. NUST will push them soon.  Any update?

UNIMAS (No update 3/8/2018, 5/3/2018)

...

  • will push them soon.  Any update?

UAF/GHZU (Updated

...

7/5/2018))

Les has implemented, and we are now successfully using the anonymous FTP server at SLAC as a proxy for gathering data from GZHU MA in Beijing.  This gets around not being able to 'get' the data via the web from the Beijing MA, due to blocks. This may also be relevant for PingER on Android gathering of data, email was sent to Amity.

Looking into moving PingER to a "blockchain" database good for decentralizing distribution of data. Monitoring sites would then be able to write to a distributed ledger. This would change the architecture to a more peer to peer architecture. It helps with continuity of PingER since reduces dependence on a single site (SLAC). See BlockChain in Future PingER Projects. Bebo sent several references to Saqib who has looked at them. We could start with real-time data without including the whole archive, i.e. in parallel to the continued centrally managed archive. It would be a private Blockchain and hence not be as compute intensive as a public blockchain.  Bebo's impression is that Saqib will lead in putting the ides in his paper into practice. Saqib will need some students.  Saqib's boss is going to the NY City meeting.

Discussion item

Saqib sent an email to the team:

In early years of PingER, the framework was designed to check the latency and other Internet performance metrics between CERN and SLAC to facilitate the data transfer between the two sites.

I am thinking, is there any possibility to use PingER to monitor the health of the Bitcoin blockchain network? Since the latency is critical in Bitcoin blockchain network as all the incentives depend on the propagation of transactions and mined blocks. Thus, I am only interested in measuring the latency to check its effect on the propagation of the transactions and mined block among different mining pools. I think if we can do such thing on a historical basis as PingER already does for the Internet, it will increase the worth of the framework and its usability.

Maybe a few test experiments can guide us to a good research paper. I am not sure about the feasibility idea, therefore, need your kind feedback

Umar responded:

"This is an interesting idea. I would like to think about it a bit more thought before I respond at length.
From what I gather, nodes in the network may appear and disappear without notice. Therefore, it is safe to assume that the network state is changing at all times. I wonder, what is it that we would be measuring, for it to be meaningful. Would it be the latency between full nodes? Would it be the latency from a PingER monitoring node to the full nodes? Would the monitoring nodes be representative of typical clients? Is latency the metric to measure? What are all the projects that measure latency or other metrics? (The bitcoin nodes project is interesting, which shows the size of the network. Similarly, the project that measures average-transaction-completion time is relevant. As you pointed out, the bitcoin stats about data exchange are relevant too.)

MA in Beijing.  This gets around not being able to 'get' the data via the web from the Beijing MA, due to blocks. This may also be relevant for PingER on Android gathering of data, email was sent to Amity.

Looking into moving PingER to a "blockchain" database good for decentralizing distribution of data. Monitoring sites would then be able to write to a distributed ledger. This would change the architecture to a more peer to peer architecture. It helps with continuity of PingER since reduces dependence on a single site (SLAC). See BlockChain in Future PingER Projects. Bebo sent several references to Saqib who has looked at them. We could start with real-time data without including the whole archive, i.e. in parallel to the continued centrally managed archive. It would be a private Blockchain and hence not be as compute intensive as a public blockchain.  Bebo's impression is that Saqib will lead in putting the ides in his paper into practice. Saqib will need some students.  Saqib's boss is going to the NY City meeting.

Discussion item

Saqib sent an email to the team:

In early years of PingER, the framework was designed to check the latency and other Internet performance metrics between CERN and SLAC to facilitate the data transfer between the two sites.

I am thinking, is there any possibility to use PingER to monitor the health of the Bitcoin blockchain network? Since the latency is critical in Bitcoin blockchain network as all the incentives depend on the propagation of transactions and mined blocks. Thus, I am only interested in measuring the latency to check its effect on the propagation of the transactions and mined block among different mining pools. I think if we can do such thing on a historical basis as PingER already does for the Internet, it will increase the worth of the framework and its usability.

Maybe a few test experiments can guide us to a good research paper. I am not sure about the feasibility idea, therefore, need your kind feedback

Umar responded:

"This is an interesting idea. I would like to think about it a bit more thought before I respond at length.
From what I gather, nodes in the network may appear and disappear without notice. Therefore, it is safe to assume that the network state is changing at all times. I wonder, what is it that we would be measuring, for it to be meaningful. Would it be the latency between full nodes? Would it be the latency from a PingER monitoring node to the full nodes? Would the monitoring nodes be representative of typical clients? Is latency the metric to measure? What are all the projects that measure latency or other metrics? (The bitcoin nodes project is interesting, which shows the size of the network. Similarly, the project that measures average-transaction-completion time is relevant. As you pointed out, the bitcoin stats about data exchange are relevant too.)
Thank you for sharing the URLs. I will think about it a bit more and get back to you."
Bebo emailed:
  • More and more I am convinced that we could identify an interesting and relevant project taking advantage of our PingER experience and involving Blockchain technology.I also think that it may be possible for us to get funding/grant money for such a project which might clearly draw the attention of Blockchain entrepreneurs, conferences, and publications. It might also allow us to attract the collaboration of other institutions and/or universities that might otherwise have not been interested in the basic PingER goals and technology.

Thank you for sharing the URLs. I will think about it a bit more and get back to you."
Though the transactional latency is important especially for achieving consensus, most of the latency is computational that is much greater than the communications latency. Possibly PingER RTT could be included in a measure of BlockChain health and status.  Bebo sent a reference (https://mastanbtc.github.io/blockchainnotes/consensustypes/) pointing out milliseconds may make a difference to miners to get rewards which is important for BlockChain cash
Saqib sent email of an analysis of the impact of various RTTs, see impact of various RTTs, see https://ethereum.stackexchange.com/questions/18201/does-network-latency-significantly-affect-mining-rewards.
A possible problem is finding the IP addresses of the bitcoin miners. Bebo dug up a URL showing how it can be done, it is at https://ethereumbitcoin.stackexchange.com/questions/1820166260/doesfinding-ip-networkaddresses-latencyof-significantlyall-affect-mining-rewards.bitcoin-miners.
Bebo will get together with Umar and Les at SLAC on Monday the 9th around noon to discuss Bitcoin/Blockchain to do some education/brain-storming. Unfortunately noon PST is 3:00am China time. We will try and send Saqib an executive overview of the discussion

PingER at SLAC (Updated 6/7/2018)

...