Versions Compared

Old Version 43

changes.mady.by.user Les Cottrell

Saved on

compared with

New Version 44

changes.mady.by.user Les Cottrell

Saved on

Key

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

...

  • Amity MA is unreliable so using it for a case study does not appear fruitful. Les is working with Amity to try and understand this unreliability (emails 10/6/2018), they say "There is an internet problem we are taking care of it and will get back soon".
  • 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)

    • It describes a multipurpose, stand-alone device that can be widely distributed, something that we have brainstormed about for a long time. 

      • We 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.

      •  They are working on a paper. They sent a  1st draft they have sent to Bebo and Les that we responded to 10/6/2018, a 2nd draft was responded to by Bebo and Les 10/13/2018. It has been submitted to EasyChair.

      • They will be attaching the android app for review after testing it again.

        • Topher  feels that the Android app (when completed and vetted by his 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.

      • Also August 16th and again September 3rd, then  October 6th and October 13th proposed a meeting between: Bebo, Umar and Les and the Amity folksLesand the Amity folks.

        • 10/24/2018: Proposed: attend a regular one hour meeting of the pingER team: Next meeting:  Tuesday, November 6th 8 pm Pacific time (Nb now on winter time); Wednesday, November 7th, 2018 9:00 am Pakistan time; 12:00 noon Malaysian & Guangzhou time; and 11 am Thailand time, 9:30 am Indian time. The downside is that the focus would be on several PingER matters as well as Amity.  However, maybe that is a good way to get started. To do this we would need thier Skype ID. I found an ID Sai Sabitha in noida, India, and we appear to have a mutual contact.  I left a message.
        • The topics are: 
          • 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 Princpal Investigator 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.
            • 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.
            • We also need to finish up the proxy acquisition of data from the Android MAs. A first step is outlined inhttps://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 you are working on (see below)
            • Also encourage Amity to put together a paper.  This appears to have been completed.
          •  Google Firebase Application (see below).
      • The paper has an interesting suggestion for a way forward - TOPIC to discuss
        • 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 file types 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.
          • Bebo agrees it is another reduction on independence from SLAC. 
          • It is unclear whether it would work for China since Google services are not available there.
          • Is it only free for low utilization. 
            • Might work for a cache for the latest data, but not for all archived PingER data (hundreds of GB). 
          • It was developed for Android applications, might be good for Android/PingER
          • There may be traffic limits.
          • Umar suggests try for one node and see how it works out in practice

...

We need to think about how to handle these hosts with both IPv4 and IPv6 addresses. Les is leaning towards moving to the future and simply changing the IPv4 addresses to IPv6 addresses. In a few cases, we may be able to find two hosts at a site, using an IPv4 address on one and an IPv6 on the other. This is the simplest solution. Doing this loses having a historical record of a target with both an IPv4 and IPv6 address. Umar and Les have some scripts that enable comparisons to be made between access to a host via its IPV4 and its IPv6 address without using the PingER data. An alternative would be to also have a pseudo name for such ambiguous hosts, another would be to modify the database schema. Both of the latter two would require changes to the code in several places. Another alternative might be to create a second record using either the IPv4 or IPv6 address as the name. This requires no changes to the code but is pretty unpleasant. If one could find a CNAME as well as the regular name then one could use the CNAME for one of the addresses and the regular name for the other as the name. This requires no changes to the code but is pretty unpleasant. If one could find a CNAME as well as the regular name (A reg) then one could use the CNAME for one of the addresses and the regular name for the other address. 

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.

...

  • Is there any statistical difference between ICMP and TCP Ping? ContextThe context here is the Internet (not data center). This is important because the network stack is different (e.g., MPI over infiniband) and latencies are significantly less.

...

  • Why should we focus on minimum RTT instead of average RTT
    • Min RTT essentially reflects fixed delay, while average RTT subsumes variations and path load
  • Are the R plots generated using minRTT?
    • Averages and computed. Min RTT is available. Scripts need to be updated to use minRTT.
  • What is the breakdown of latency between endpoints?If there is a difference, is it because of the type or location of the source? What if the source of traffic was not SLAC?
  • Is there a correlation with the distance between the end pointsendpoints?
  • Are the differences limited to a particular region? How do we determine/understand if traffic prioritization is implemented?
    • It may be that end hosts which are farther away have larger variances and thus the pronounced differences.
  • Test in a controlled environment to avoid variables such as traffic prioritization, queuing delay due to cross traffic.
  • Review the time series of latencies for both ICMP and TCP ping, instead of averages?
  • Is there a difference between IPv4 measurements vs IPv6.

...

Next meeting:  Tuesday, November 6th 8 pm Pacific time (Nb now on winter time); Wednesday, November 7th, 2018 9:00 am Pakistan time; 9:30 am India time; 12:00 noon Malaysian & Guangzhou time; and 11 am Thailand time.

...