Page History

...

See: http://pinger.unimas.my/pinger/contact.php

• Need to add Umar and Dr. Taha - Johari

Attendees

Invitees:

Wajahat Hussain+ (SEECS), Saqib+ (GZHU); Johari? (UNIMAS);  Adib? (UUM); Dr. Charnsak Srisawatsakul? (Ubru), Les+, Bebo+, Umar?-

• + Confirmed attendance

...

• ; - Responded but  Unable to attend:

...

• ? Individual emails sent

Actual Attendees

 Wajahat, Saqib, Les, Bebo, Taha (Skype ID nightwingduck, email taha.ali@seecs.edu.pk)

Others

 Charnsak was in another meeting but listening in to our meeting.

Administration

• Membership of pinger-my in  is in https://groups.google.com.
• Saqib points out: "Normally, on Friday at 12 noon, I am out of the lab and my mobile internet connection is not good to participate in the skype meeting. For the next time, is it possible for all to change the meeting day from Thursday to Wednesday according to Pacific time?"

Amity (Updated 8/6/2018)

• Amity MA is unreliable so using it for a case study does not appear fruitful.
• 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. 

  • Bebo mentioned it to Topher and he feels that their 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. 

  • Bebo asks: should we try to increase our communication with Amity and do we have faith that they would follow through?

  • How should we proceed? 

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

    • Also encourage them to put together a paper.

    • Also August 16th and again September 3rd proposed a meeting between: Bebo, Umar and Les. and the Amity folks. No response

Thailand (No update 8/9/2018)

...

• We polled the attendees and decided to move it to Tuesday Pacific time.
• 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.

Action Items

• Future meetings are moved to Tuesdays Pacific time.
• Bebo: will try and contact Dr. A. Sai Sabitha to see how to move forward with the Android PingER project, in particular, schedule a meeting. 
  • Les will forward recent emails to Amity, to Bebo. - Done
• Wajahat: will provide a list of working or potentially working (e.g. being worked on) Pakistani MAs to Les.
  • Les: if they are not enabled, Les will enter them into the database or re-enable the gathering of data from these MAs
    
• Saqib and Les: are working on being able to gather data from  2001:da8:270:2018:f816:3eff:fef3:bd3 IPv6 node in Beijing working again.
• Umar: update his section on the comparison IPv6 vs IPv4 ping RTTs and TCP vs ICMP/ping RTTs.
• Johari: enter Umar and Dr. Taha into http://pinger.unimas.my/pinger/contact.php
• Charnsack: We need to get the latest pinger2.pl measurement agent script installed at Ubru so we can get better logging and see

...

• why the

...

•  other hosts are not being monitored.

...

• Les: will invite Dr. Taha to join the pinger-my email list. - Done. 

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

  • Bebo mentioned it to Topher and he feels that their 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. 

  • Bebo asks: should we try to increase our communication with Amity and do we have faith that they would follow through?

  • How should we proceed? 

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

    • Also encourage them to put together a paper.

    • Also August 16th and again September 3rd proposed a meeting between: Bebo, Umar and Les. and the Amity folks. No response. Bebo will try and contact 

Thailand (No update 8/9/2018, No update 9/6/2018)

For his IPv6 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 according to pingtable.pl there are only about 13 targets responding. We need to get the latest pinger2.pl measurement agent script installed at Ubru so we can get better logging and see why the other hosts are not being monitored.   Charnsak plans to remedy in August.

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)

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)

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 Development: https://www.journals.elsevier.com/world-development

NUST:

• 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. Still down 8/6/2018.  It has been Disabled so data is no longer being gathered. 
• pinger.isra.edu.pk unable to gather data since 3/6/2018, also does not ping. It is working as of September 2nd, 2018.
• Wajahat says they will get these nodes up. These have been good nodes. They just need the weekly push. NUST will push them soon.  No update 8/9/2018.

UAF/GHZU (Updated 8/9/2018)

Saqib's future at GZHU will be much clearer after 3 months (i.e. November). His current contract expires February 2019. 

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.
• Umar has not made much progress on the comparisons of IPv6 vs IPv4 or TCP vs ICMP.  
• 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 identified and sanitized a Cross Site Scripting (XSS) exposure in ping-data.pl. He will send out a notice to please update. He still needs to do this.
• Les is cleaning up the Beacons (i.e. removing non-responders and replacing, adding Beacons for countries with no Beacons).
• There is a problem gathering data from  2001:da8:270:2018:f816:3eff:fef3:bd3 the Guangzhou IPv6 host in Beijing. Since it does not use the standard way of gathering data (ping_data.pl), but instead uses anonymous FTP, the standard way of debugging the problem does not work.  This would also affect debugging problems on Android PingER MAs since they do not support a web server.

Next Meeting

Next meeting:  Tuesday October 9th 9 pm Pacific time; Wednesday October 10th, 2018 9:00 am Pakistan time; 12:00 noon Malaysian & Guangzhou time; and 11 am Thailand time.

...

Old information

Umar looking at extending the comparison IPv6 vs IPv4 ping RTTs and TCP vs ICMP/ping RTTs. Last update  6/7/2018

• See Towards Analysis of ICMP vs TCP Ping Latencies - Umar
  • Looked into Traffic Differentiation - Rate Limiting vs. Traffic Prioritization (QoS)
    • Conclusions: 
      • Min RTT essentially reflects fixed delay, while average RTT subsumes variations and path load
      • TCP Segment drops manifest as large increases in delay
      • QoS can be implemented in at least two ways: 
        • When priorities are implemented, ICMP packets will only be dropped if ICMP quota is full and link is congested, otherwise ICMP traffic is allowed to go beyond quota
        • When rate-limits are implemented, ICMP packets will be dropped when ICMP quota is met, even if links are not congested
      • Path loads dictate latency estimates: With weighted QoS implementations, loaded links depress ICMP
    • Found relevant papers and technical reports. The intent here is to understand the components of latency to help with the evaluation.

      • Y. Zhang, N. Duffield, V. Paxson, S. Shenker, On the Constancy of Internet Path Properties, in ACM SIGCOMM Internet Measurement Workshop 2001

      • A. Acharya, J. Saltz, A Study of Internet Round-Trip Delay, Univ of Maryland, Tech Rep. CS-TR-3736

      • M. Allman, V. Paxson, On Estimating End-to-End Network Path Properties, in ACM SIGCOMM 1999

      • V. Paxson, G. Almes, J. Mathis, Framework for IP Performance Metrics

    • Setup NeuBot and experimented with tests but wasn't able to find useful examples of traffic differentiation (see https://www.measurementlab.net/tests/)
    • Skimmed Glasnost to understand traffic shaping (see http://broadband.mpi-sws.org/transparency/glasnost.php and https://github.com/marcelscode/glasnost)
    • [Not Relevant] Miscellaneous notes on ICMP Traceroutes, MPLS tunneling & ICMP (see http://cluepon.net/ras/traceroute.pdf), Measuring Performance

  • IPv6 results gathered using ping-vs-tcp.pl script. About 56 nodes with IPv6 addresses, 14 of which responded with Npings

  • IPv4 results gathered from SLAC and Virginia Tech
    • SLAC's batch may be downloaded here (approx. 24 MB)
    • Skimmed results; findings are pretty much the same as before
• Pending
  • Identified relevant events in the network stack that highlight timing (_RECVFROM, _RECVMSG, _IP_RECV, _NETIF_RX etc.). Looking for instrumentation that enables us to measure timestamps. We also need to figure out how to determine whether ICMP & TCP traffic are treated differently? and then how to measure the difference?
    • perf-tools allows us to measure transport events
    • If we could assume that the path for ICMP & TCP through the network is the same, then the only difference between two (controlled) tests would be the time spent in the transport layers. This can be measured using perftools. 
    • However, such measurements must be made in a controlled environment where ICMP and TCP are treated the same. (I say so because some results — e.g., in East Asia and South Asia — clearly show that ICMP performs much worse than TCP.)
  • We would also need to cater for cross traffic and queuing delays. Given how small the differences are, one may argue that the variations in measurements are due to cross traffic. Perhaps we should start with controlled tests and then see if real world measurements reflect similar behavior.
  • We need to setup a test environment. We can either setup a bare-metal box or use a VM. 
    • I will see if I can arrange for a bare-metal box.

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)

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 email 8/6/2018. 9/3/2018.

UUM (No update 8/9/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 Development: https://www.journals.elsevier.com/world-development

NUST: (Updated 7/5/2018, no update 9/8/2018)

• 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. Still down 8/6/2018.  It has been Disabled so data is no longer being gathered. Should it be re-enabled?
• pinger.isra.edu.pk unable to gather data since 3/6/2018, also does not ping. It is working as of September 2nd, 2018.
• Wajahat says they will get these nodes up. These have been good nodes. They just need the weekly push. NUST will push them soon.  No update 8/9/2018.

UAF/GHZU (Updated 78/9/2018)

Saqib's future at GZHU will be much clearer after 3 months. His current contract expires February 2019. 

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 comment/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.
• Umar has not made much progress on the comparisons of IPv6 vs IPv4 or TCP vs ICMP.  
• 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 (Updated 6/7/2018, no update 8/9/2018)

Umar looking at extending the comparison IPv6 vs IPv4 ping RTTs and TCP vs ICMP/ping RTTs. 

• See Towards Analysis of ICMP vs TCP Ping Latencies - Umar
  • Looked into Traffic Differentiation - Rate Limiting vs. Traffic Prioritization (QoS)
    • Conclusions: 
      • Min RTT essentially reflects fixed delay, while average RTT subsumes variations and path load
      • TCP Segment drops manifest as large increases in delay
      • QoS can be implemented in at least two ways: 
        • When priorities are implemented, ICMP packets will only be dropped if ICMP quota is full and link is congested, otherwise ICMP traffic is allowed to go beyond quota
        • When rate-limits are implemented, ICMP packets will be dropped when ICMP quota is met, even if links are not congested
      • Path loads dictate latency estimates: With weighted QoS implementations, loaded links depress ICMP
    • Found relevant papers and technical reports. The intent here is to understand the components of latency to help with the evaluation.

      • Y. Zhang, N. Duffield, V. Paxson, S. Shenker, On the Constancy of Internet Path Properties, in ACM SIGCOMM Internet Measurement Workshop 2001

      • A. Acharya, J. Saltz, A Study of Internet Round-Trip Delay, Univ of Maryland, Tech Rep. CS-TR-3736

      • M. Allman, V. Paxson, On Estimating End-to-End Network Path Properties, in ACM SIGCOMM 1999

      • V. Paxson, G. Almes, J. Mathis, Framework for IP Performance Metrics

    • Setup NeuBot and experimented with tests but wasn't able to find useful examples of traffic differentiation (see https://www.measurementlab.net/tests/)
    • Skimmed Glasnost to understand traffic shaping (see http://broadband.mpi-sws.org/transparency/glasnost.php and https://github.com/marcelscode/glasnost)
    • [Not Relevant] Miscellaneous notes on ICMP Traceroutes, MPLS tunneling & ICMP (see http://cluepon.net/ras/traceroute.pdf), Measuring Performance

  • IPv6 results gathered using ping-vs-tcp.pl script. About 56 nodes with IPv6 addresses, 14 of which responded with Npings

  • IPv4 results gathered from SLAC and Virginia Tech
    • SLAC's batch may be downloaded here (approx. 24 MB)
    • Skimmed results; findings are pretty much the same as before
• Pending
  • Identified relevant events in the network stack that highlight timing (_RECVFROM, _RECVMSG, _IP_RECV, _NETIF_RX etc.). Looking for instrumentation that enables us to measure timestamps. We also need to figure out how to determine whether ICMP & TCP traffic are treated differently? and then how to measure the difference?
    • perf-tools allows us to measure transport events
    • If we could assume that the path for ICMP & TCP through the network is the same, then the only difference between two (controlled) tests would be the time spent in the transport layers. This can be measured using perftools. 
    • However, such measurements must be made in a controlled environment where ICMP and TCP are treated the same. (I say so because some results — e.g., in East Asia and South Asia — clearly show that ICMP performs much worse than TCP.)
  • We would also need to cater for cross traffic and queuing delays. Given how small the differences are, one may argue that the variations in measurements are due to cross traffic. Perhaps we should start with controlled tests and then see if real world measurements reflect similar behavior.
  • We need to setup a test environment. We can either setup a bare-metal box or use a VM. 
    • I will see if I can arrange for a bare-metal box.

PingER IPV6 support

• Les identified and sanitized a Cross Site Scripting (XSS) exposure in ping-data.pl. He will send out a notice to please update.
• Les is cleaning up the Beacons (i.e. removing non-responders and replacing, adding Beacons for countries with no Beacons).

Next Meeting

Next meeting:  Thursday, September 6th 9 pm Pacific time; Friday, September 7th, 2018 9:00 am Pakistan time; 12:00 noon Malaysian & Guangzhou time; and 11 am Thailand time.

...

Discussion item (7/5/2018)

...