...
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 Block Chain 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. Bebo's impression is that Saqib will lead in putting the ides in his paper into practice. Saqib will need some students. Saqib's oss boss is going to the NY City meeting.
...
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.
- 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
- Min RTT essentially reflects fixed delay, while average RTT subsumes variations and path load
- 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
- Conclusions:
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
- Looked into Traffic Differentiation - Rate Limiting vs. Traffic Prioritization (QoS)
- 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.
- 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?
...