# Network Measurement and Performance Analysis at Server Side
## 2 Related Work  
We discuss the existing work related to network performance measurement in the following categories:  
**Packet level analysis. ** Several tools analyze packet traces to find performance bottlenecks. T-RAT [7] analyzes packet traces collected at core routers and outputs diagnostic results similar to EVA. However, T-RAT does not consider congestion control variations and therefore lacks generality. Our work can be seen as an extension of T-RAT in modern network environments. Everflow [8] collects packet-level information in large datacenter networks for scalable and flexible access. However, it relies on \"match and mirror\" functionality of commodity switches, and our solution does not. Other tools measure wireless network performance [9; 10; 11; 12]. [PERSON] et al. [9] passively monitored GPRS network performance by analyzing TCP packets at the ingress/egress router interface. [PERSON]. [10] monitored home wireless network performance in the home wireless access point. [PERSON] et al. [11], [PERSON] [12] measured the performance of mobile networks, but the goals are different. [PERSON] et al. [11] focused on heavy-users in 3G networks and [PERSON] [12] monitored network traffic to optimize the 3G networks. **Instrumenting the network stack. ** Monitoring the network stack is more lightweight comparing to our packet-level approach. In particular, TCP states and application behaviors can be observed at very low cost. SNAP [13] pinpoints performance problems similarly to EVA. However, it leverages TCP statistics (number of bytes in the send buffer, total number of fast retransmissions, etc.) and socket-level logs (the time and number of bytes whenever the socket makes a read/write call) in network stack. Similarly, NetPairot [4] collects TCP statistics at each machine's hypervisor or within individual VMs to identify root causes of failures. Comparing to EVA, these tools are too intrusive since they must run inside the server. **Measurement in switches. ** Some tools uses flow-level information (NetFlow [14] and sFlow [15]) collected on switches to provide support for different measurement tasks. However, flow-level information cannot provide good fidelity comparing to our fine-grain packet monitoring. As an alternative, many sketch-based streaming algorithms have been proposed [16; 17; 18; 19]. However, these algorithms are tightly coupled to the intended metric of interest, forcing vendors to invest time and effort in building specialized hardware. In contrast, our solution is software-only and thus more generic. In addition, compared to our end-hosts approach, monitoring in switches provides more visibility but limited support for measurement (i.e., programmability and processing power). Therefore, various query languages [20; 21; 22] and switch hardware [22] have been proposed. As an alternative, SwitchPointer [23] combines the advantages of both, i.e., resources and programmability of end-hosts and network visibility of switches. EVA does not use network visibility of switches; instead, it abstracts any arbitrarily complex path into a single link with the same propagation delay and bottleneck rate. **Measurement in mobile devices. ** To monitor mobile network performance, an promising approach is to use smartphone apps [24; 25; 26; 27]. These tools focus on wireless network (3G/4G, WiFi) and mobile devices performance. 4 GTest [25] is a network performance measurement app with distributed server support globally. It actively measures the network RTT and throughput. There are two main differences between 4 GTest and EVA. First, EVA runs near the server, and it pays more attention to the server side performance. Second, EVA measures network conditions passively, while 4 GTest takes a active approach. **Other performance measurement solutions. ** Several works analyze network performance in different ways. [PERSON] et al. [28] measured TCP end-to-end performance in a simulated mobile network. They focused on the interactions between the mobile network architecture and TCP.