4 ms·

I think the point was they conduct the speed test from the same servers that deliver video content. So ISPs can't throttle video streaming without it showing up

I think the point was they conduct the speed test from the same servers that deliver video content. So ISPs can't throttle video streaming without it showing up in this speed test.

greenspot 10y ago
Makes sense but wouldn't they then use the netflix domain? Something like netflix.com/fast? I could image that if providers throttle it would be a mix of IPs and domain.
- chrishacken 10y ago
  Some ISP's (we don't throttle anything) throttle based on several factors, mainly packet signatures. Traffic coming from big/known sources, such as Netflix, contain unique signatures (probably the headers, etc, that are unique to Netflix Traffic). You can then check all incoming packets that match those signatures and throttle them. So unless Netflix went out of their way to mask every request to look like video content, there's not a whole lot you could do.
  - IceyEC 10y ago
    The files that fast.com has you download ARE chunks of video files :)
    - zeristor 10y ago
      Does anyone know which video the test file is? Perhaps it's encrypted, or a Netflix promo piece. Wouldn't there be copyright issues to use their actual streaming licences content?
      - niftich 10y ago
        Earlier I got curious and I was wondering this too. Seems to be a 'random' blob of bytes every time that doesn't decode, but then I remembered they serve DRM'ed video that is then decrypted on the client.
      - corobo 10y ago
        If you have a Netflix subscription it's probably this or something like this [1]. For non-flixers it's a calibration video similar to [2] [1] https://www.netflix.com/watch/80103278 https://www.netflix.com/watch/80103278 [2] https://www.youtube.com/watch?v=cGgf_dbDMsw https://www.youtube.com/watch?v=cGgf_dbDMsw
  - WatchDog 10y ago
    The connection is encrypted, the ISP can't see request headers. For the main data download, all they can determine is its an TLS connection to a netflix content server. Potentially you could do some stateful monitoring looking for recent requests to fast.com but it's generally much harder to implement than simple IP or SNI based profiling.
  - stouset 10y ago
    All of the traffic is HTTPS. The ISP doesn't get to see headers.
- dpark 10y ago
  If you look at the actual traffic, it's hitting netflix's content servers. e.g. ipv6_1-lagg0-c001.2.bne001.waia.isp.nflxvideo.net The interesting traffic is not to fast.com.
- voxic11 10y ago
  If you look they aren't using fast.com as the domain they are downloading files from. That's just the domain that hosts the page. It doesn't matter if it gets throttled because it only serves up a few kb of html.
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.

I think the point was they conduct the speed test from the same servers that deliver video content. So ISPs can't throttle video streaming without it showing up in this speed test.

greenspot 10y ago

Makes sense but wouldn't they then use the netflix domain? Something like netflix.com/fast? I could image that if providers throttle it would be a mix of IPs and domain.

chrishacken 10y ago
Some ISP's (we don't throttle anything) throttle based on several factors, mainly packet signatures. Traffic coming from big/known sources, such as Netflix, contain unique signatures (probably the headers, etc, that are unique to Netflix Traffic). You can then check all incoming packets that match those signatures and throttle them. So unless Netflix went out of their way to mask every request to look like video content, there's not a whole lot you could do.
- IceyEC 10y ago
  The files that fast.com has you download ARE chunks of video files :)
  - zeristor 10y ago
    Does anyone know which video the test file is? Perhaps it's encrypted, or a Netflix promo piece. Wouldn't there be copyright issues to use their actual streaming licences content?
    - niftich 10y ago
      Earlier I got curious and I was wondering this too. Seems to be a 'random' blob of bytes every time that doesn't decode, but then I remembered they serve DRM'ed video that is then decrypted on the client.
    - corobo 10y ago
      If you have a Netflix subscription it's probably this or something like this [1]. For non-flixers it's a calibration video similar to [2] [1] https://www.netflix.com/watch/80103278 https://www.netflix.com/watch/80103278 [2] https://www.youtube.com/watch?v=cGgf_dbDMsw https://www.youtube.com/watch?v=cGgf_dbDMsw
- WatchDog 10y ago
  The connection is encrypted, the ISP can't see request headers. For the main data download, all they can determine is its an TLS connection to a netflix content server. Potentially you could do some stateful monitoring looking for recent requests to fast.com but it's generally much harder to implement than simple IP or SNI based profiling.
- stouset 10y ago
  All of the traffic is HTTPS. The ISP doesn't get to see headers.
dpark 10y ago
If you look at the actual traffic, it's hitting netflix's content servers. e.g. ipv6_1-lagg0-c001.2.bne001.waia.isp.nflxvideo.net The interesting traffic is not to fast.com.
voxic11 10y ago
If you look they aren't using fast.com as the domain they are downloading files from. That's just the domain that hosts the page. It doesn't matter if it gets throttled because it only serves up a few kb of html.

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.