CoNEXT'16 Session 11: Measurements and diagnosis 2

1. "Measuring Latency Variation in the Internet", (short paper) 
Toke Høiland-Jørgensen (Karlstad University), Bengt Ahlgren (SICS), Per Hurtig (Karlstad University), and Anna Brunstrom (Karlstad University)

Internet latency has large variations that can come from many sources. Although the network throughput has been largely increased over the past few years, both the minimum Internet latency and the latency variation have not been improved over time. This works focuses on measurement the latency variation experienced by a client by utilizing the extensive publicly available dataset from the Measurement Lab Network Diagnostic Tool (NDT) with a packet capture from within a service provider access network.

It is found out that there is significant regional differences in the datasets. For instance, Africa, Asia, Europe and America all have different RTT values. There are multiple sources that can cause such latency variations, including queueing delay along the path, delay acknowledgements, transmission delay, medium access delay, etc. One main source for Internet latency variation is the queueing delay along the path. The measurement results show that the queueing delay is a non-trivial number of instances and when the queueing delay occurs, it has significant impact on the network performance.

Q: In your experiments, where do you measure the latency?
A: We focused on the path from client to the server, in the TCP handshake delay measurements.

Q: The connection setup time, for example, the setup time for TCP connections, is critical. Have you look into the connection time to different servers such as Google, Facebook, etc.?
A: That should be useful measurements but we haven't done that in this work.

Q: An thoughts on extending this work to the end-to-end latency?
A: We definitely think about the metrics, but however, the current datasets and platform limit such measurements. Will look into it in the future.


2. "LossRadar: Fast Detection of Lost Packets in Data Center Networks",Yuliang Li (Yale University), Rui Miao (University of Southern California), Changhoon Kim (Barefoot Networks), and Minlan Yu (Yale University)

Packet loss diagnostics is very important in data centers. Packet losses come very common at large-scale data centers. Nowadays, it usually take a very long time for data centers to detect and locate packet losses. Packet losses can have high impact on data centers' performance: it will increase the latency, drop the throughput, and break the connection between clients and the servers. There is no effective ways today to track the root causes and there are many challenges in doing so. Unfortunately, existing monitoring tools that are generic in capturing all types of network events often fall short in capturing losses fast with enough details and low overhead.

Therefore, we design LossRadar, which is a system that can capture individual lost packets and their detailed information in the entire network on a fine time scale. A high level idea of this approach it that each switch mixes all the packets they see in a small data structure. The same packets in the data structure will cancel out and only the loss packets will remain. The traffic digests are built using Invertible Bloom Filter structure, which has a table associated with multiple hash functions. Each packet will be hashed by each hash function.

LossRadar is demonstrated to be easily implemented using P4 language. LossRadar is evaluated in simulations using 80 switches from 28 hosts with 10G links. Simulation results show that the memory usage is very low, for 10G traffic, LossRadar only needs less than 8kb to catch the losses. LossRadar is also compare to state-of-the-art approaches and LossRadar is shown to have lower memory, while achieving a good performance. The P4 code of LossRadar is also released on github.

Q: Can you explain a bit more about how the loss differentiation algorithm works?
A: The different types of losses are described in three dimensions and the bursty is quantified by the timestamp of each loss.

Q: Can LossRadar be extended to handle the packet loss at the end host (not in the switch)?
A: Yes it can! Just need to install the meter in the server to detect the loss, it's the same as detecting losses between the switches.

Q: Have you evaluated the performance overhead on the forwarding path?
A: It doesn't affect the data path of the packets.


3. "Demystifying and Puncturing the Inflated Delay in Smartphone-based WiFi Network Measurement", (short paper)
Weichao Li (The Hong Kong Polytechnic University), Daoyuan Wu (Singapore Management University), Rocky K. C. Chang (The Hong Kong Polytechnic University), and Ricky K. P. Mok (CAIDA/UCSD)

We have a lot of apps measuring the latency of the network on our mobile phones, but how about their accuracy? Are they doing exactly what they are supposed to do? This work present the measurements of network-level latency, instead of the popular user-level latency, and looks into the source from the kernel space instead of from the users. The two main contributions of this work is (i) energy-saving mechanisms - theSecure Digital Input Output (SDIO) bus sleeping and the IEEE 802.11 Power Saving Mode (PSM) - are the main sources of the delay inflation, and (ii) the design, implementation, and evaluation of AcuteMon, which is an Android app prototype run on unrooted phones and requiring no system customization, such as kernel recompilation and customized ROM.

Controlled experiments are produced on several phone models to collect the delay from the network and from the drivers. Experimental results achieve very accurate network RTT and show that the delay overheads can be largely mitigated by the proposed approach.

Q: All the experiments are under controlled environments, have you conducted experiments in real-world where there may be interfering WiFi transmissions?
A: We are actually doing that right now and we have also done experiments in the wild.

Q: Have you measured the power consumption of the measurement?
A: We haven't done so since we focused on measuring the delay. But we will look into it in the future.

Q: How about the delay in 3G/4G networks?
A: We have had results for 3G/4G networks in terms of delay measurements, but they are not in this paper.