Techniques for Detecting Discrimination in Streaming Services

Table of Links

Abstract & Introduction

Related Work and Background

Challenges in TD Detection Measurement Setup Development

Case Study : Wehe - TD Detection Tool for Mobile Environment

Shortcoming of Wehe on HTTPS Traffic

TD Detection of HTTPS Traffic

Conclusion & References

II. RELATED WORK AND BACKGROUND

As net-neutrality regulations were hotly debated in many countries, several authors have proposed methods to detect any net neutrality violations or deliberate traffic discriminations in the Internet. Recent surveys [1], [2] cover all the tools and techniques used by them. The literature is also rich with various forms of discrimination and its detection, like discrimination of content providers [3], end-users [4], specific services like BitTorrent [5]. Our focus in this work is on detecting discrimination of streaming services (both audio and video) that constitute a major portion of internet traffic and consume significant bandwidth. We discuss some of the tools and techniques that is most relevant to our work.

A. Existing TD detection tools

There are two commonly used techniques for detecting TD in users’ Internet traffic. One type of approach passively monitors traffic [6]. In such cases, the end-result or TD result is not immediately available to the user. Instead, the tool provides the aggregated result of traffic differentiation over the given ISP. Another type of detection technique uses specially crafted probing traffic - called Active probes. It analyses network response to probing traffic to detect any anomaly. [6]–[10] describes measurement setups based on such active probing. It uses traffic parameters such as packet loss, latency, packet sequence, or pattern to identify network operation characteristics or detect anomalies. Some tool uses multiple types of probing traffics called active differential probes. While one probing traffic type undergoes standard network middle-box processing, the other probing traffic type is supposed to evade any traffic differentiation by being not amenable to middle-box processing. Typically, in such differential probe methods, one traffic type mimics characters of traffic of services accessed from the original server (like Youtube, Netflix). The other is a reference or control traffic. In this method, network responses to both traffic streams are compared to check if performance of any stream suffered against the other. [11]–[13] are examples of such probing techniques. The differential probe method uses a common server to stores the content of services of interest, and this content is collected from the original servers. The common server thus replays the content and mimics the characteristics that original servers impart in the transfer of their content, like maintaining timing relationships between data packets. In the differential probe, traffic from the replay server must be treated similarly to that treated from the original servers. When it comes to HTTPS traffic, the current tools do not ensure that traffic from replay servers is treated as that originated from an actual server and our work fills this gap.

B. Traffic replay mechanisms

The traffic replay mechanism mimics the client and serverside behavior for given application data exchange and the underlying protocol. There are many traffic replay tools available. Tcpreplay [22] is one such replay tool that mimics the transport layer behavior for the given stream of transport

Fig. 2. Traffic classification of Gmail video play traffic with direct browser accesses and from user-client (TLS handshake not same as browser based access)

layer packets. Another example of a layer-specific replay is FlowrReplay that runs at the application layer. The layerspecific replay tools are many times protocol dependent. The technique roleplayer proposed in [23] is capable of replaying application layer data in a protocol-independent manner. The replay layer selection (refer Fig. 1) for traffic replay is crucial as it affects the receiver side’s data collection as well as expected network response. The TCP layer replay adversely affects the traffic analysis as it requires special permission to collect traffic data for analysis.