How Glasnost works

Glasnost ist based on a client-server architecture. Clients connect to a Glasnost server and loads a Java applet that performs measurements between the client and the server. Thereby, Glasnost emulates application traffic, like BitTorrent, and measures the throughput for transfers in upstream and downstream direction. To allow accurate measurements you should stop any large downloads (e.g., BitTorrent) that might run in the background.
After the test is done, the website will display the results of the tests.

To run the Glasnost test, users need to install a Java plugin for their browsers. The Java plugin can be downloaded for free for many operating systems from here.
We produced a signed version of the applet for MacOS X users. This is necessary that the applet can run successfully in the Apple Java Virtual Machine as it uses some unique policy settings. To run this test, you have to "trust" the applet in the pop-up window that will appear once you started the test. This allows the applet to access the system property "sun.arch.data.model" (it is used to determine how many bits the underlying architecture uses) which is needed by the java.nio.channels.Selectors class.

 

Glasnost emulates a pair of transfers that are identical except in one respect that we suspect triggers differentiated treatment of transfers along the Internet path.
The figure on the right illustrates this. Glasnost's first flow is an application flow, like in this case a BitTorrent flow. The second flow, called the reference flow, is identical to the first flow as it has the same number of messages, the same message size and the same message order, but replaces the packet payload with random bytes instead of the BitTorrent protocol messages. This allows Glasnost to detect whether transfers are blocked or throttled based on the application sending the network traffic (details on this can be found in the next section).

To also detect whether transfers are blocked or throttled based on the TCP port used, we send transfers on the defailt application port (e.g., 6881 for BitTorrent) as well as a port not associated with any popular application (e.g., 10001).

Glasnost tests uploads and downloads, the user's host will first act as a sender and then as a receiver.

 

Glasnost detects traffic differentiation. This means that packets of one transfer are treated differently than those of another transfer. Glasnost distiguished and detects two types of traffic differentiation:

• Application-based differentiation: To decide whether a certain transfer should be throttled or blocked, the network packets are inspected to infer which application sends it.
• Port-based differentiation: Transfers on a particular TCP port are throttled or blocked no matter which application sends the it.

Glasnost currently supports the detection of two traffic differentiation policies:

• Blocking: Transfers are interrupted, either by dropping all packets of the transfer or by injecting TCP RST packets. (you can find more information about this type of throttling in our IMC 2008 paper Detecting BitTorrent Blocking.)
• Throttling: Transfers are slowed down to some bandwidth cap. This can be done in various ways, e.g., by delaying or dropping network packets. (you can find more information about this type of throttling in our NSDI 2010 paper on Glasnost.)

Glasnost detects two types of blocking: First, if a transfer stalls after the first one or two packets the transfer and cannot transfer any more packets, we consider this as blocking. Second, Glasnost detects whether transfers got terminated by forged TCP RST packets, injected by a traffic shaper in the Internet path (you can find a more detailed description of this detection technique in our IMC 2008 paper Detecting BitTorrent Blocking.)

Glasnost detects throttling by comparing the throughput of a transfer pair. To detect application-based throttling, we compare the throughputs of an application transfer (e.g., BitTorrent) with its corresponding reference transfer. To detect port-based throttling, we compare the throughput of an application transfer (or the reference transfer) on two different ports, where one of the port is usually a default application port. (you can find a more detailed description of this detection technique in our NSDI 2010 paper on Glasnost.)

To account for transient noise in our measurements, we repeat each measurements multiple times and also run each transfer for a sufficient long time so that the throughput of a transfer can stabilize. Comparing the repeated measurements with each other allows us to quantify the transient noise and exclude measurements that appear to be too noisy for an accurate inference of traffic differentiation.

 

For details on our research on broadband networks please refer to our network transparency project webpage

In case you have questions about this tool or our research, please contact us: