3 ms·
If it's intentional throttling, fast.com would actually not be much of a problem. It'd still be easy to selectively apply traffic shaping to streaming but not t
by jsnell 10y ago
If it's intentional throttling, fast.com would actually not be much of a problem. It'd still be easy to selectively apply traffic shaping to streaming but not to the speedtest traffic.
It would be harder (though not impossible) if there is an actual capacity problem, and the bottleneck is outside of the ISP's network. For example insufficient peering capacity, which seems to be where most of the Netflix / ISP friction is.
- kbenson 10y ago> 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 makes it obvious when your ISP is quietly throttling your video streaming traffic. Since it's a win-win in this respect, I would be surprised if this isn't exactly what they are doing.
- jsnell 10y ago> 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.
- davb 10y ago> but there are still multiple simple ways to distinguish the current speedtest testcase Like looking out for DNS queries for fast.com then handling traffic from that client differently for a period (such as the A record's TTL).
- kbenson 10y ago> 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 article or some other source that outlined this. It would fairly trivial to send sample content of actual video content for the test, and emulate a streaming client on the tester side, so I'm not sure how an ISP would distinguish traffic in that situation.
- jsnell 10y agoSure. 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.
- jonknee 10y agoThe same functionality can surely be built into Netflix apps.
- kbenson 10y agoSo in that case Netflix just decides to have their streaming clients occasionally access fast.com before regular streaming to get any traffic shaping eased? I agree, that in this case, where a separate domain was used, ISPs can use that to detect a speed test is likely. That said, I would like to note that every solution an ISP has to implement is much more expensive to any mitigation put forth by Netflix, as long as they want to hide what they are doing. If they aren't hiding it, well that's one of the reasons netflix is doing this, to inform customers what they are actually getting from their ISP, and let them make choice whether they like the current product they are using from their ISP (if they have a credible choice).
- brazzledazzle 10y agoNetflix could load something from fast.com on each Netflix navigation right? Ultimately if they're playing cat to Netflix's mouse how much does each mitigation strategy cost them relative to Netflix? I wonder if it's more cost effective to process that much traffic through shapers than it is to increase bandwidth between peers or allow Netflix to drop their boxes within their networks.