EBU response to the public consultation on the draft BEREC report 'Monitoring quality of Internet access services in the context of net neutrality'

Transcription

1 BoR PC02 (14) 11 EBU response to the public consultation on the draft BEREC report 'Monitoring quality of Internet access services in the context of net neutrality' The European Broadcasting Union (EBU) welcomes the opportunity to respond to the draft BEREC report on 'Monitoring quality of Internet access services in the context of net neutrality'. The EBU and its members public service media organisations from 56 countries across Europe and beyond are strong supporters of an open, neutral and transparent public Internet. Safeguarding transparency to end users and preventing degradation of services and content online by creating effective systems monitoring the quality of Internet access is essential in order to achieve net neutrality in Europe. That s why the EBU strongly supports the work BEREC is doing in this field. Work undertaken by BEREC will also establish a solid basis for much needed practical tools for National Regulatory Authorities (NRAs) to enforce open Internet provisions both at national level and EU level, in particular the regulatory provisions proposed in the European Commission s connected continent proposal and recently improved by the European Parliament in first reading. With its response, the EBU would like to reiterate the importance of measurements beyond the ISP leg and of transparency of the actual data throughput of the service delivered by an ISP. It also provides an overview of relevant monitoring techniques that are used already or can be used in future with regard to net neutrality for broadcasters and other content providers. First of all, we support the BEREC recommendation that the measurement beyond the ISP leg should be used to account for the connectivity of the ISPs interconnection to the Internet. Such measurement allows testing the real-world throughput an ISP can provide to connect an end-user to the open Internet. Data throughput is important for end-users to be able to consume media services over the Internet. Watching video or listening to radio will not be possible if the speed varies or the service is interrupted frequently. Broadcasters often use adaptive streaming techniques to modify the real-time viewing quality to match the current available speed without interrupting the continuity of the video. However, if the speed drops substantially, the audio or video cannot be displayed. Thus, transparency of the actual current throughput of the service delivered by an ISP is essential. Open Internet exchanges (IXPs) are the most important measuring location as content providers have the possibility to influence their connection to this entity. An ISP can use different interconnection arrangements between other ISPs and content providers, and thereby manipulate data traffic. This could be done by limiting an ISP s connection to an IXP. Therefore we think the available throughput to an open IXP is most important. We are of the opinion that NRAs should be active in providing and provisioning the infrastructure required for network neutrality related network measurements. ISPs do not deliver these real-time figures themselves and could even filter out information that might be gathered in their network like trace-route information. Throughput and other measurements as depicted below are only practical if there are appropriate servers available in different IXPs or other well-connected gateways. The ISPs are considered UNION EUROPEENNE DE RADIO-TELEVISION L Ancienne-Route 17A Tél. +41(0) BP Le Grand-Saconnex Genève, Suisse

2 to be a black box and the first available open connection to the Internet can be used to install servers with measuring tools. If the data were open this infrastructure would not be required by the market, but the current situation means that measurement provisions can only be implemented at national level with central investments and NRA involvement. Thus, the appropriate NRA can oversee the measurements and take action if needed on basis of their own findings. The way broadcasters monitor the performance of the Internet is typically using plugins for software players. These tools detect problems such as package loss, ping speeds to nearest caches buffer under run, switching between different bitrates, and start-up times that all influence the consumer s Quality of Experience (QoE). Variations in video quality can be influenced by the choice of content delivery network (CDN), stream source failures and client-side buffering in real-time. But such monitoring won't tell you if an ISP is simply flooded (which is not a network neutrality question), or that it is actively degrading your connection quality for your content (which is a network neutrality question). Therefore we propose an approach to monitoring that can identify forms of network neutrality violations with statistical certainty. Telecom operators have the ability to artificially degrade or even block some Internet services, and have been known to use this ability. Blocking a service, while drastic, is also easy to detect. More subtle network degradations (e.g. inducing additional delay) are just as effective a disruption to media services, but can be the result of other users activity in the same geographical neighbourhood. Since the Internet is a best-effort service, it is hard to distinguish between such temporary congestion and deliberate artificial degradation. Below we describe various methods to make that distinction, thereby removing the plausible deniability from ISPs and providing transparency into their network management policies. Below, you ll find a technical overview of possible degradations, along with the selection criteria an ISP may use to decide whether or not to apply the degradation to a particular service. It then provides examples of measurement setups to highlight that degradation beyond reasonable doubt. Earlier in this document, we have outlined the technical requirements to build an appropriate measurement setup. As an introduction, we refer to the image below as the architectural map of the Internet: 2/6

3 Purely as example: Say you (client B) find vimeo.com (Service B) slower than youtube.com (Service C). Is this because YouTube/Google have better hosting (connected to router C)? Or is this because your ISP (at router E) is slowing Vimeo down? There are many reasons why vimeo.com might be slower, yielding plausible deniability for the ISP: maybe Client C is downloading something from Service A, congesting the D-E link, Types of degradation A typical user experience is the sum of a number of different layers working together. The top layer, the one the user interacts with, is called the Application Layer. For example, this might be a web browser the user uses to surf to a given website. It can also be service specific application, such as a smartphone app, or a SmartTV OTT (Over the Top) channel. This application does not do all the hard work itself, but uses underlying layers such as the Session and Presentation Layers (where the TLSprotocol is responsible to secure HTTP requests into HTTPS requests), the Transport Layer (which will attempt to reorder out-of-order segments, recover lost segments, etc.) and the Network Layer (which does the actual end-to-end delivery of IP packets). An ISP only transports packets at this lower Network Layer, and thus cannot (directly) impact the layers above it. Thus an ISP cannot (directly) cause a video-player to rebuffer, it can however delay IP packets, which may or may not cause a particular player to deplete its buffer. 3/6

4 It is therefore necessary to translate observed behaviour back-and-forth between the effects on the Network Layer, the Application Layer and ultimately the user experience. Only limited possibilities exist to influence traffic at a packet level. A packet can be delivered immediately, delayed or discarded. Looking at a stream of packets, there are a number of additional factors that could degrade traffic: increased jitter: the addition of delay to only some packets limiting the throughput: allow a certain number of packets (or bytes) per second to pass unhampered, but drop (or delay) packets above this threshold Technically, a packet can also be corrupted (have its content changed), but this is usually detected by an upper layer, and treated the same as that packet being lost. The effects of these degradations on the user experience vary depending on the severity of the degradation, and the protocol used. Voice-over-IP calls for example are quite sensitive to jitter, while video-streaming requires a high sustained throughput. Types of triggers for the degradation of services Network neutrality covers degradations that are only applied to a portion of an ISP s traffic. There are various criteria to establish whether a particular packet/flow might be affected: Time of day, day of week Type of service: o TCP/UDP port o protocol (RTP, RTMP, ) o Content of the media container: audio-only, or audio+video? Source/destination IP addresses Protocol header values o HTTP Host:-header o HTTP UserAgent:-header Measurement methods There are several existing measurement methods available, such as the ones provided by M-lab ( They tackle the problem by combining (averaging) many thousands of clients. If the traffic degradation is done based on service (i.e. all video-streams are slowed down), these tests can demonstrate this. If the impairment is applied on a source/destination basis, these tests can only show that a particular site is slower on a particular ISP compared to other ISPs, but they don't identify whether that ISP causes this slower behaviour intentionally. To really identify artificial degradations based on source/destination, more in-depth techniques are needed, such as those suggested by Dan Kaminsky in his "Black Ops of TCP" presentation ( and Extra latency based on HTTP-header Suppose an ISP introduces an additional 50ms delay on all packets belonging to an HTTP-session with host The policy is activated by the HTTP Host:- header. 4/6

5 This behaviour can be detected by measuring the difference in round-trip time (RTT) of a baseline measurement, and an affected measurement: Baseline: Measure the RTT for a connection establishment (TCP SYN until TCP SYN-ACK). Since these packets are exchanged before any Host:-header is sent, they are equal for all web-traffic. Affected: Measure the RTT of the normal data flow. Since these packets are exchanged after the Host:-header, the policy will be triggered. Since there is no technical reason why a packet carrying a connection request should be any faster than a regular packet (of the same size), these two measurements should yield the same value (after statistical averaging). If there is a statistically significant difference, the artificial degradation has been exposed. Throttling based on HTTP-header Suppose an ISP limits the throughput of a HTTP-session with host The policy is activated by the HTTP Host:-header. This behaviour can be detected by measuring the difference in throughput of a baseline measurement, and an affected measurement: Baseline: Measure the throughput of a dummy web-service running on a controlled server, which is known to be on a net neutral Internet connection. Affected: Measure the throughput of a clone of the affected web service on the same controlled server (e.g. by setting up a proxy and making sure that all content is cached). Since the traffic is coming from the same physical server over the same network path, there is no technical reason why these two measurements should be different. If there is a statistically significant difference, the artificial degradation has been exposed. Increasing loss based on IP-address Suppose an ISP adds additional loss to a TCP-based video streaming session with a particular (set of) IP address(es). The policy is activated by matching the source IP address in the packets, and requires the full TCP-connection to be visible. To detect this behaviour, we need an additional controlled server, which is known to be on a net neutral Internet connection. Additionally, it needs to be able to send out IP packets with someone else's source IP address (IP spoofing). A VPN between the measurement client and this server allows the client to send out packets to the Internet which can't be inspected by the ISP's policy engine because they are encrypted. This behaviour can be detected my measuring the difference in packet loss of a baseline measurement, and an affected measurement: Baseline: Measure the packet loss of a TCP-connection between the client and the controlled server Affected: Set up a specially crafted asymmetric TCP-connection: o The client sends a connection request over the normal Internet connection, but makes sure that this packet does not reach the final 5/6

6 o o o o target (e.g. by setting the TTL too low). An additional copy of this connection request is send over the VPN to the controlled server. The controlled server initiates a connection with the affected IP address. Replies from the affected IP address, received by the controlled server, are reflected back to the client (outside of the VPN) with spoofed IP addresses. From the ISP's point of view, these look like replies to the original connection request of the client. All further communication from client to server is sent out both via the normal connection (but these should not reach the destination), and though the VPN, where the controlled server will relay them All further communication from the affected server to the controlled server are reflected to the client Since the traffic is, in both cases, coming from the same physical server, over the same network path, both connections should have the same packet loss rate. If there is a statistically significant difference, the artificial degradation has been exposed /6