Page History

...

• How should we proceed? 
  • We (Topher and the PingER team) agreed to request Amity to share the App and instructions with us; we will look at installing on a jailbroken Android phone at the San Francisco end and try it out.
    • Instructions from Aayush to load the application are at ePingER Functional prototype (for Androids only)
    • We also need to finish up the proxy acquisition of data from the Android MAs. A first step is outlined in https://confluence.slac.stanford.edu/display/IEPM/Proxy+support+for+PingER. 
      
  • A later step is to look at, evaluate and find resources to implement the ideas expounded in the Future Proposals section of the paper Amity is  working on (is there a more recent copy)
• Amity demonstrated the Android/ePingER application via a shared screen. 
  
• Currently they can upload the data from the App to an FTP server at Amity.
  • Given concerns about security, there was a discussion about replacing with something a bit more modern such as using a centralized cloud so all can access the data. Amity are looking at Firebase:
    • Firebase Application: The need for a proxy server can be completely eliminated by shifting to a cloud-based architecture for managing files. Instead of SLAC pulling in the generated txt files from MAs around the world, the MAs can themselves push these files to a centralized application server hosted on the cloud; which makes it easier for SLAC to access files as per their need. Considering the great degree of integration capabilities Google offers with its products, the flexibility arising from using the Google Cloud Platform would be pronounced. Google’s Firebase is a mobile and web application development platform that provides developers with a variety of tools and services to help develop high-quality apps, that can scale easily as per changing demands, and which delivers 99.99% uptime. The Firebase SDK allows mobile app developers to quickly add critical and reliable functionality to their applications in a short time. The recommended option here would be to leverage the Cloud Storage for Firebase that allows robust uploads and downloads onto the Google Cloud Storage buckets. Apart from the user authentication module that comes bundled with Firebase, developers can also declare file security parameters so as to allow only certain filetypes to be uploaded. Having all user uploaded files in one place will then enable SLAC to access and process files as and when needed. Server-side processing can be done on the Google Cloud Platform as well, thereby eliminating any need for SLAC to maintain its own physical infrastructure. This form of implementation can be highly beneficial in any kind of region of the world, also including remote places, like deep inside tropical rainforests, or places that have recently been hit by a natural calamity. As this implementation model is not dependent on any local measuring agent, the Android mobile apps can directly deliver data to SLAC over any form on internet connection in minimal time with high reliability. 
    • For the initial stages, FTP is sufficient, the Firebase model allows much greater scalability, especially as the number of Android/ePingER MAs increases.
  • There was also a discussion about utilizing the mobility aspects of Androids in particular with regard to cell towers.  
    • This would probably require adding GPS information (Lat/Long) to the actual measurements.
      • This would be easy to implement in the MA.
      • To be backward compatible we would need to make it easy to ignore this extra information.
    • A concern raised was that cell mobility results in huge changes in RTTs. The current PingER analysis is based on static MAs and is typically based on looking at changes in performance based on more global and temporal influences such as social unrest, earthquakes, tsunamis, economics, education, development etc. Understanding the effects of mobility would require new analyses.
    • The consensus was that, at least in the near term, the current PingER dataflow/analysis would not change. It would/could use the data from Android/ePingER static MAs.
      • This implies the current PingER dataflow/analysis is extended to identify mobile (non-static) MAs, and hence ignore them or treat them differently.  Les does not think this is difficult to incorporate once we decide on the format etc.
• Actions:
  • Amity will annotate the image of the Amity participants (see image above) with their names. Les sent an email reminder 1/5/2019.
  • Amity will send SLAC the final copy of the paper to be presented at a Confluence conference 1/11/2019 entitled. Les sent email reminder 1/5/2019.
    • It would also be helpful if Amity would set up an email list for the Amity team and share the information. A possible name might be pinger-am
  • Topher will look at installing the Android App on an Android phone at the San Francisco end and try the Android/ePingER application out.
    
  • Topher asked for which PingER web sites to look at for understanding PingER.  Les later sent the following:

    • Start data aStart at the  PingER home page at http://www-iepm.slac.stanford.edu/pinger/. Some important links are:

      Various Reports (under the Reports tab) in particular 

      •  How Bad is Africa's Internet
      • IEEE Paper 2000
      • Mapping the Digital Divide
      • 2017 Annual Report
      • A Giant Leap in 2016

      Case studies

      For users who want to look at the data see Results/data tab,.

      Introductory stuff

      •  Under About tab

      Under Maps 

      •  Website map (mainly for developers)
  • Les will work with Amity to see if they are going to add GPS information to the MA measurements and if so to understand the format and how to ignore them in the PingER dataflow/analyses.
  • Les will contact Amity to see how to collect their Android/ePingER data. Les sent email 1/5/2018.

...

...