Page History

...

• + Confirmed attendance; - Responded but  Unable to attend; ? Individual emails sent

Actual Attendees

Wajahat, SaqibSaqib (but we were unable to hear him), Dr Shadi Aljawarneh, Umar, Les, Bebo, Taha 

Others

...

• Membership of pinger-my is in https://groups.google.com.
• Bebo pointed out that the International Web Conference will be in San Francisco in 2019 (see http://www.wikicfp.com/cfp/servlet/event.showcfp?eventid=77195&copyownerid=85335).  There are a whole range of topics. He would love to see something submitted related to PingER.
  • Maybe something on Android PingER and potential uses.
• Bebo, possible interest in an MA in Jordan - 10/9/2018.
  • It is a university of Science and Technology.
  • Bebo is looking to send the Home page: http://www-iepm.slac.stanford.edu/pinger/, plus  Remote Host site invitation letter template, Monitor Host site invitation letter template:(txt, doc), form to register a host to the contact. 
  • They will attend this meeting. Dr. Shadi Aljawarneh <shadi.jawarneh@yahoo.com> skype ID shadi Jawarneh

Action Items from previous meeting

• Figuring out how to move forward with the Android PingER project, in particular, scheduling a Skype meeting probably later this week.
• Wajahat: will provide a list of working or potentially working (e.g. being worked on) Pakistani MAs to Les. They are working on nodes as of email 10/6/2018.
• Johari: enter Umar and Dr. Taha into http://pinger.unimas.my/pinger/contact.php, Les sent reminder email 10/3/2018.

Amity (Updated 8/6/2018, No update 9/6/2018)

Jordan 

• We discussed the many uses of PingER data including:
  • the impact on network performance of events such as earthquakes, tsunamis, civil uprisings, the world cup, 
  • exploring the data semantically e.g. byLinked Open Data
  • Correlations with other indices such as economics, human development.
• We also discussed:
  •  development of new low cost, low power PingER Measurement Agents (MA) utilizing Android devices.
  • the possibilities of developing/utilizing a decentralized logging/analysis/presentation structure using BlockChain. This would reduce the dependence on SLAC.

Action Items from previous meeting

• Figuring out how to move forward with the Android PingER project, in particular, scheduling a Skype meeting awaits Amity. 
• Wajahat: will provide a list of working or potentially working (e.g. being worked on) Pakistani MAs to Les. They are working on nodes as of email 10/6/2018.
• Johari: enter Umar and Dr. Taha into http://pinger.unimas.my/pinger/contact.php, Les sent reminder email 10/3/2018. No progress 11/16/2018

Amity (Updated 8/6/2018, No update 9/6/2018)

• 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/2018Amity 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".  Meeting planned soon

...

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 (No update 8/9/2018, no update 9/6/2018, no update 10/7/2018, no update 11/16/2018)

Need to add Umar Kalim to http://pinger.unimas.my/pinger/contact.php. From the 7/5/2018 meeting: 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.

Sent reminder emails 8/6/2018. 9/3/2018.

UUM (No update 8/9/2018, No update 9/6/2018, 11/16/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

...

Gathering data is no longer working, is there some  some way to fix it?

Blockchain

• 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. 
• There was a meeting to discuss blockchain possibilities, see 20180709 PingER Meeting on Blockchains. 
• Bebo's impression is that Saqib will lead in putting the ides in his paper into practice. Saqib will need some students.  Saqib is OK with this. He has 2 masters students but they are working in different areas.  Maybe NUST can assist with this. Saqib's partner gave a talk/paper on work so far at the New York meeting on July 31st. The talk went fine but there were not many comments/questions.
• Saqib is pursuing PingER and Blockchain. He is looking at different references shared by Prof. Bebo and the implementation details using Hyperledger Fabric. Saqib is looking at making a test implementation. The blocksize will be 2MB-10MB. It does not appear to be computationally expensive. He will start testing with Internet of Things measurements such as humidity and temperature
• There was a discussion on the use of DataBases and whether they could be avoided by caches. Hyperlogic keys are not in an SQL DB, basically, it appears like a cache.  There was a question whether a 10MB block would be adequate for PingER. For example, PingER from SLAC has about 700+ targets, the measurements are each 30 mins (48/day) and for pings of 100B and 1000 Bytes i.e. 2*48*700 measurements and each measurement is ~ 140Bytes, so a day's sets of measurements from just SLAC is ~ 10MBytes. We could choose to ignore the 1000Byte pings which would reduce it to ~ 5MBytes/day. The latency of retrieving a block is proportional to the block size. Things will be clearer after the test set up is in use.

IPv6 measurements

• There are now several months of IPv6 PingER measurements from GZHU/BJ, UBRU and SLAC. It is time to think about in-depth analysis of the data.
• The PingER measurements would provide longer time spans where one might look for changes with time such as diurnal changes, impact of holidays, anomalies etc. 

PingER at SLAC 

PingER IPV6 support

• Les cleaned up the Beacons and added some more hosts. Now have 161 Beacons in  156 different countries, all are working.
• We now monitor 830 targets from SLAC this is an increase of ~100 in the last year and is the most monitored from SLAC ever.
• We are monitoring 48 IPv6 nodes from SLAC.
• There is a problem gathering data from  2001:da8:270:2018:f816:3eff:fef3:bd3 the Guangzhou IPv6 host in Beijing. 

Context:

• Is there any statistical difference between ICMP and TCP Ping? The 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.

Questions:

• 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 endpoints?
  • Latency for an echo packet to travel up the stack and back down is about 3.75 micro seconds (see StackMap https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata). As expected, this is negligible when considered with milli second latencies.The remaining components would be propagation and queuing delay. As we cannotbreakdown the two in a public network without using an active look like
    • To replicate use system tap. See: https://unix.stackexchange.com/questions/419449/how-can-i-determine-if-a-latency-is-due-to-a-driver-or-the-scheduler
  • pathchirp etc, we'll continue to consider these as a single component.
• Are the differences limited to a particular region? How do we determine/understand if traffic prioritization is implemented?Test in a controlled environment to avoid variables such as traffic prioritization, queuing delay due to cross traffic.
  • It may be that end hosts which are farther away have larger variances and thus the pronounced differences.
• 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

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.

...

We were unable to hear Saqib. By text messages, he indicated he is looking at getting the Beijing Measurement Agent working again.  He is trying to make the Beijing MA live again. However, he has little control over it as it was in CERNET cloud.

After the meeting Umar and Saqib experimented with using Zoom instead of Skype.

PingER at SLAC 

PingER IPV6 support

• Les cleaned up the Beacons and added some more hosts. Now have 161 Beacons in  156 different countries, all are working.
• We now monitor 830 targets from SLAC this is an increase of ~100 in the last year and is the most monitored from SLAC ever.
• We are monitoring 48 IPv6 nodes from SLAC.
• There is a problem gathering data from  2001:da8:270:2018:f816:3eff:fef3:bd3 the Guangzhou IPv6 host in Beijing. 

Context:

• Is there any statistical difference between ICMP and TCP Ping? The 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.

Questions:

• 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 endpoints?
  • Latency for an echo packet to travel up the stack and back down is about 3.75 micro seconds (see StackMap https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata). As expected, this is negligible when considered with milli second latencies.The remaining components would be propagation and queuing delay. As we can not breakdown the two in a public network without using an active look like
    • To replicate use system tap. See: https://unix.stackexchange.com/questions/419449/how-can-i-determine-if-a-latency-is-due-to-a-driver-or-the-scheduler
  • pathchirp etc, we'll continue to consider these as a single component.
• Are the differences limited to a particular region? How do we determine/understand if traffic prioritization is implemented?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?
  • It may be that end hosts which are farther away have larger variances and thus the pronounced differences.
• Is there a difference between IPv4 measurements vs IPv6.

Next Meeting

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.

...

Old information

GZHU moved 11/28/2018

Blockchain

• 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. 
• There was a meeting to discuss blockchain possibilities, see 20180709 PingER Meeting on Blockchains. 
• Bebo's impression is that Saqib will lead in putting the ides in his paper into practice. Saqib will need some students.  Saqib is OK with this. He has 2 masters students but they are working in different areas.  Maybe NUST can assist with this. Saqib's partner gave a talk/paper on work so far at the New York meeting on July 31st. The talk went fine but there were not many comments/questions.
• Saqib is pursuing PingER and Blockchain. He is looking at different references shared by Prof. Bebo and the implementation details using Hyperledger Fabric. Saqib is looking at making a test implementation. The blocksize will be 2MB-10MB. It does not appear to be computationally expensive. He will start testing with Internet of Things measurements such as humidity and temperature
• There was a discussion on the use of DataBases and whether they could be avoided by caches. Hyperlogic keys are not in an SQL DB, basically, it appears like a cache.  There was a question whether a 10MB block would be adequate for PingER. For example, PingER from SLAC has about 700+ targets, the measurements are each 30 mins (48/day) and for pings of 100B and 1000 Bytes i.e. 2*48*700 measurements and each measurement is ~ 140Bytes, so a day's sets of measurements from just SLAC is ~ 10MBytes. We could choose to ignore the 1000Byte pings which would reduce it to ~ 5MBytes/day. The latency of retrieving a block is proportional to the block size. Things will be clearer after the test set up is in use.

IPv6 measurements

• There are now several months of IPv6 PingER measurements from GZHU/BJ, UBRU and SLAC. It is time to think about in-depth analysis of the data.
• The PingER measurements would provide longer time spans where one might look for changes with time such as diurnal changes, impact of holidays, anomalies etc. 

Thailand moved 11/17/2018

...