Building fast.com

Post by jonknee » Tue, Aug 09, 2016, 8:38 PM UTC

IshKebab wrote: post #73

nippoo wrote: post #60

This is beautiful. By using Netflix's actual CDN and requesting actual video files over HTTP, they're preventing ISPs from whitelisting fast.com without also whitelisting Netflix itself. Of course there'll be a game of cat-and-mouse with DPI, but it's a super-neat way of making it much harder for the ISPs to misrepresent actual video download speed...

Yeah right. Just wait until a user visits fast.com and unthrottle their connection for 20 minutes. I strongly suspect some ISPs already do that with speedtest.net.

Post by davb » Tue, Aug 09, 2016, 8:40 PM UTC

jsnell wrote: post #55

kbenson wrote: post #47

Earlier quoted context omitted.

> It'd still be easy to selectively apply traffic shaping to streaming but not to the speedtest traffic. That presumes they aren't fully emulating streaming traffic to test speed. Not only is this the correct thing to do from a video streaming company that wants to test connection speed for their services (the quantity and size of packets can affect the delivery through different mediums and devices), but it also mak…

> That presumes they aren't fully emulating streaming traffic to test speed. It's not really a presumption, it's the actual facts on the ground. The actual benchmark file is served over HTTPS from, but there are still multiple simple ways to distinguish the current speedtest testcase from normal streaming.

Post by imglorp » Tue, Aug 09, 2016, 8:42 PM UTC

Citrus2fizz wrote: post #74

Hows this for a discrepancy https://i.imgur.com/7SX2Wro.png

Post by dpcx » Tue, Aug 09, 2016, 8:45 PM UTC

randartie wrote: post #80

What's stopping ISPs from slowing down other speedtests at the same rate as netflix to eliminate your ability to have a 'control'?

Post by kbenson » Tue, Aug 09, 2016, 8:50 PM UTC

jsnell wrote: post #75

kbenson wrote: post #65

Earlier quoted context omitted.

> The actual benchmark file is served over HTTPS from, but there are still multiple simple ways to distinguish the current speedtest testcase from normal streaming. Do you mind explaining the details you are aware of that lead you to think they are not emulating streaming traffic in at least some portion of their test (since they are testing multiple sessions and types of traffic)? I may have missed a portion of this…

Sure. One example is that someone doing a speedtest will have accessed fast.com before starting a download of video streams. This can be detected despite the the encryption, e.g. via looking at the SNI of the requests. It doesn't matter what the video stream looks like, since those separate TCP flows can be cross-correlated.