Page History

...

• 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? Discussion

Thailand (Updated 7/5/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. Les and  Charnsak are working on this.  - Charnsak progress?   Charnsak plans to remdy next week.

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.

...

Bebo's impression is that Saqib will lead in putting the ides in his paper into practice. Saqib will need some students.  Saqib's boss is going to the NY City meeting.There was a meeting to discuss bitchain possibilities, see 20180709 PingER Meeting on Blockchains.

Discussion item

Saqib sent an email to the team:

In early years of PingER, the framework was designed to check the latency and other Internet performance metrics between CERN and SLAC to facilitate the data transfer between the two sites.

"I am thinking, is there any possibility to use PingER to monitor the health of the Bitcoin blockchain network? Since the latency is critical in Bitcoin blockchain network as all the incentives depend on the propagation of transactions and mined blocks. Thus, I am only interested in measuring the latency to check its effect on the propagation of the transactions and mined block among different mining pools. I think if we can do such thing on a historical basis as PingER already does for the Internet, it will increase the worth of the framework and its usability.

Maybe a few test experiments can guide us to a good research paper. I am not sure about the feasibility idea, therefore, need your kind feedback"

Umar responded:

...

PingER at SLAC (Updated 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.

PingER IPV6 support

• PingER now seems to be fully IPv6 capable and stable, the logs have been improved to make it easier to debug problems.
• Les identified and sanitized 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).

Bebo 

Discussion

Bebo sent email:

More and more I am convinced that we could identify an interesting and relevant project taking advantage of our PingER experience and involving Blockchain technology.

For example,

https://bitcoin.stackexchange.com/questions/66260/finding-ip-addresses-of-all-bitcoin-miners <https://bitcoin.stackexchange.com/questions/66260/finding-ip-addresses-of-all-bitcoin-miners>

I also think that it may be possible for us to get funding/grant money for such a project which might clearly draw the attention of Blockchain entrepreneurs, conferences, and publications. It might also allow us to attract the collaboration of other institutions and/or universities that might otherwise have not been interested in the basic PingER goals and technology.

...

Next Meeting

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

...

1. They are using the native java tools, they are not running the pinger2.pl <http://pinger2.pl>  script on android since the native java tools have the following advantages
   1. easier for user, 
   2. no need for prior installation of any software, e.g. load perl interpreter which may require missing skills, especially for a non technical user
   3. doesn't need a rooted phone
   4. only the apk needs to be installed to run

2.  They have fixed the final sequence number change by using regex, and  pushed these changes to github repository.

3. They have installed apache tomcat in the server and plan to use a java file on the server which would connect to the phones that send the request. This java file will then take the input stream received from the phone and write the output stream to a file that would be stored on the server. We are facing some problems regarding a blocked port that is not allowing the phone to connect to the server we are currently working on resolving the issue.

4.  SLAC can then regularly pull these files which would be stored based on the month they are received. 

5. The Android students have started writing a paper on " implementation  of pinger  on android " .

6. Next steps:

   1. Extend the target list by getting the Beacon list from SLAC. It is at http://www-iepm.slac.stanford.edu/pinger/pinger.xml on a regular basis and updating the <BeaconList> section at their site. This was part of pinger2.pl. 

   2. Also they will need a utility to clean out old recorded data (say older than 3 months), since it will be gathered from SLAC (via the proxy) and eventually they may run out memory on the Android.

Discussion

To a large extent it depends on how we plan to use this.

...