Time
Scheduled for 7:00pm January 15, San Francisco time (this is 8:30 am January 16, India Standard Time).
There was a long delay in starting, eventually heard from Amity and started at 7:30pm
Invitees
Bebo White, Saqib Ali, Les Cottrell - SLAC, Bebo had to leave at 7:10pm and so missed the meeting which started at 7:30pm.
naman madan <naman.madan25@gmail.com, aayush.2896@gmail.com, assabitha@amity.edu - Amity
Method
We met by Zoom (see https://zoom.us/). Each attendee will need the Zoom app.
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/9258476228
Or iPhone one-tap (US Toll): +18333021536,,235375142# or +16507249799,,235375142#
Minutes
Bold face refers to new items discussed at the meeting, normal face is background to assist in understanding.
Accessing pinger data in Firebase
Go to https://firebase.google.com/ enter the Google account pingeramity123@gmail.com plus the password (Les has the password). Then Go to console, then choose one of the documents (e.g. pinger-7db5c. To the left is a columns with items such as Authentication and Database.
Under Authentication +919999999999 is the guest access.
The Database provides access to the data, click on ping and the individual records show up. Click on + signs to open each record.
Currently a set of measurements is initiated manually.
Next steps:
- Amity will provide a video of what was discussed (i.e. how to access the data etc.)
- Need to automate the measurements, Amity will investigate
- Need to provide access to the data in text format for a specified time window.
- The default format is jason, as a start we need to provide flatfile text access, 1 line per record, Les will provide the text format. It is available at PingER Monitor node format
- The lat long of the Android MA needs to be added
- At some stage (number of users, volume of data/number of records saved in Firebase etc.) we need to gather the data and delete it to save space and possible charges.
- Ayush and Naman will investigate how much data can be saved before we will be charged, this will determine how often we need to gather and delete the current data.
Future step:
- Amity will provide the app for an Android once the app is more stable.
Naman and Ayush shared their screen and made a demonstration of how to access the data in Firebase
~~~~~~~~~~~~~~~~~~~~~
Older Information
Moved here 1/15/2020
The Android version of the PingER MA, is described with comments at ePingER on Android Native - Amity project (this a proposal/description from Aayush Jain)
- Amity's documents describe a multipurpose, stand-alone device that can be widely distributed, something that we have brainstormed about for a long time.
- Bebo mentioned it to Topher (the Principal Investigator (PI) of the RainForest project) and he feels that the Amity PingER/Android app (when completed and vetted by Topher’s team) could easily be installed as a default service on his rainforest monitors (certainly future ones, not devices already in place). Merging the service data that he already collects with that unique to PingER has the potential to lead to some interesting results.
- Since the above Topher has been consumed with RainForest projects and will not have time to devote to PingER/Android.
- A question is whether he can provide Android's and is this needed anyway? Bebo indicated he will get hold of Androids.
The topics are: :
- How should we proceed?
- Back in January 2019, 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.
- 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)
- In January they could 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.
- At the January meeting we agreed that for the initial stages, FTP is sufficient, the Firebase model allows much greater scalability, especially as the number of Android/ePingER MAs increases.
- The Firebase archiving is now working. It supports authentication with a userid. It is accessible via the web. Once one has signed in you can use the app.
- The testing has 4 or 5 Beacons. Beacons are static.
- The MA will support mobility.
- The idea is to add the location (lat/long) of the Android MA to the data records, e.g. by putting the lat/long at the end of the current records separated by a semi-colon (';').
- There is a Google API to get the Lat/long.
- Amity plan to update the records with the lat, long data in a week. They will mail the update with the lat, long included.
- Access is by WiFi or the phone.
- The phone will cost by volume of data transferred.
- The app is a native App and available from the Android store (Play store). It has been vetted by Google.
- If the target is mobile then the MA and the PingER database will need to be extended to use the phone number of the client since it will probably not have a permanent IP address.
- There is currently no talk of adding the lat, long of the beacons
- 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.
- Some thoughts on mobility can be found at PingER and mobility.
- There was a request from Amity on how to access the SLAC data for Case Studies.
Saqib
Saqib has submitted and had accepted a concept note “ePingER - Android based Internet Performance Monitoring Agent to measure & analyse the Digital Divide in remote areas of Pakistan.” He is now working on the next stage of the proposal. There was a comment from the evaluators:
- It would be good to prepare how to ensure that there is a beneficial effect as a result of making these measurements, and what is the practical outcome for people in the country.
Saqib will look at comparing both a native App and a perl based one. Obviously the low power requirements and possibility of using solar power and batteries is very important for remote areas. The benefits are identifying and understanding the network performance, response time, ability to make phone calls, diurnal variations, reliability, data transfer rates expected. Sharing this information and recommendations with the carriers should assist with identifying what upgrades are required and improve the ability or the local people to communicate with the outside world. Improved communications should assist in knowing when and where to market goods, share information among the community, access information from elsewhere etc.
The full and final proposal should be sent to asiaconnect-call@teincc.org by 23:59 KST (GMT +9:00) 6th November.
Jammu Kashmir
Given the unrest in Jammu Kashmir Les added a couple of targets in Jammu Kashmir. The idea is to see if the unrest is reflected in the ping performance. The hosts in JK are :
| Project Type D means it is Disabled, no longer being monitored (since it is only a few msec from SLAC and hence a proxy that is not in JK), so we only have 2 targets in JK |
|
| |
The two hosts are shown in the map below:
Status of Amity MA
The problem with Amity MA reliability continues. Why is it unreliable, can anything be done?
The problem is that the utility power source goes down each night.
The MA is a desktop. It probably draws over a 100 Watts, thus a UPS for say 12 hours would be very expensive.
A possibility might be to port it to a low power device such as an Android or Blackberry Pi. They draw a few watts, so a smaller cheaper UPS might do the job. Some thoughts on this can be found at ePingER on Android phone.
Actions:
- Amity will mail the update with the lat, long included.
- Amity will annotate the photo captured of the Amity team in the meeting.
- SLAC also needs to know how to access the Firebase data.
- Once that is known and the data with lat, long included and we understand the format and how to access it, Les will look at how to incorporate in a backward-compatible fashion into the current PingER.
- Bebo will get hold of some Android phones and once he is given instructions on accessing the native app look at experimenting.
- Amity will look to see if they know of any targets in Jammu Kashmir.
- Next meeting will be in a month.
- Amity will set up a google poll to determine the date and time
- The current time of 20:00 in the US and 08:30 at Amity is appropriate.
- Amity will set up and notify the team of the meeting by Zoom. If this is a big problem Les can set up the Zoom meeting.
