NOTE: Please consider the following notes as more of a brain dump instead of a well thought out document.
Table of Contents |
---|
Update 06/07/2018
- 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
What are we investigating?
...
2) Instantiate a GNU screen or tmux session on a server that will not be turned off for a couple of days. or tmux session on a server that will not be turned off for a couple of days.
I believe we need a terminal multiplexer; many a times I have interrupted long running jobs when I have closed a terminal window by mistake and lost the session, or that I have to disconnect my laptop from the server and I lose the session. These multiplexers, when instantiated on the server, allow us to spawn the measurement process under their tree. We can then disconnect from the server and reconnect at a later stage. (I personally prefer tmux. However, screen is equally good. Here is some useful documentation on tmux.)
3) Executing the script includes passing it the necessary arguments and pipe the output to a file. I tend to prefer tee so that I may also see the output on the terminal, while it is being saved to a file. Please see the command below, which was executed under a tmux session.
Code Block |
---|
$ sudo ./ping-vs-tcp.pl --prot 4 --port 80 --count 3 | tee 2018-03-02-ps-v4-uk.log |
...