I personally avoid cable ISPs precisely because of this kind of junk. Other option is DSL (Verizon), but it's unfortunately 3 Mbit/sec max in many cases. If you are lucky you get 7 or even 15, but it's not common (only if you are very close to the Verizon station). Some rare places have fiber optics, but it seems they stopped expanding it. In general the situation in US is horrible - I still don't understand why there is no competition. Are there any artificial barriers?
My Verizon DSL is peaking at about 1 mbit/s: http://imgur.com/a/2yXOT . Our plan should be providing 1.1-15. Given that per youtube.com/my_speed, most people on my ISP are getting much better speeds I'm wondering if it's due to my setup. I can't imagine what could be wrong though: it's a Linksys WRT54G running latest version of Tomato firmware, I'm on a MacBook Air.
Verizon has several DSL plans (one up to 1.5 Mb/s, and then 3 and 7 or 15). In some areas 7 and up are simply unavailable, but I didn't hear that 3 wasn't an option. Try contacting Verizon about it.
Im in Sd also, Mission Valley. Only cable here is Comcast. They must be doing the same crap I think because a lot times the.Hd videos on youtube .wont work unless I wait ten minutes for them to buffer
Being able to dump the ISP would require a marketplace of ISPs to choose from. However, in the US, regulatory capture has prevented such a marketplace from forming.
Any new entrant has to build out a cable plant to reach subscribers and capture enough subscribers at a high enough density to make it worthwhile. The only company that's even trying at this point is Google.
1. I presume that the capital costs of infrastructure in creating a new ISP are significant.
2. Most of the larger markets are in densely populated cities, which makes laying infrastructure even more difficult (there's a reason that Verizon rolled out FiOS to suburban areas rather than urban areas).
3. If your 'value added' is something that the ISPs can easier undercut to drive you out of business (e.g. expanding bandwidth caps, increasing speeds), then your business proposition becomes even shakier.
Yes, typically cable companies have been granted monopolies within a municipality. In municipalities where cable companies have refused to upgrade infrastructure, and municipalities have attempted to build out fiber infrastructure to homes, cable companies have used the courts to delay movement by the municipality. Cable companies have also been pushing through laws on the state level to prevent municipalities from ever building out their own data infrastructure.
My immediate thoughts exactly. The other competitor in my area currently can't go beyond 12 mbps down while TWC offers 20 mbps down and more.
There was a young upstart I had high hopes for, but I was out of their area. They are http://www.widerangebroadband.net/ and their customer service was great, but unfortunately I'm just outside their area at the moment.
20mbps from TWC is fine for YouTube for me. I don't seem to have the filtering problems the others have. I also stream Netflix fine. Sometimes the HTML5 player glitches, but that's about all I can report. Another part I didn't mention above is that the 20mbps plan bumps me to a higher up-speed plan, making remote work less laggy, etc.
I have been screaming at YouTube for being crap, especially lately. Five seconds of a video would play, then I'd get like a thirty-second pause -- with NO pre-load. I thought this was Google being even cheaper than they have been (doing away with total pre-loads) but now I find out it's been TWC! My god! They should be fined into non-existence.
The odd thing is, on my primary desktop PC, I am rarely served ads. If I use a Win 7 notebook via WiFi, every YouTube video starts with an ad -- even if it's a video I just watched on the desktop that had no ad. Go figure...
I've been having a similar in Canada on Teksavvy DSL, but I'm not sure if it's network congestion because Bell is screwing TSI or if it's some youtube caching issue (or maybe both).
If anyone on Teksavvy has a workaround, please let me know. Thanks.
Another anecdotal "yes" seems to be working much faster for me. Versus skipping, slow load times, random freezes, and, impossible to play any youtubes in HD quality at all. Now, I can stream them. I've had many friends around me complaining about YouTube quality as of late, so interesting thread/discussion and quick-fixes.
I've had a non-cable DSL connection for years through the same independent provider and noticed about 6-12mos ago that YT was doing the partial-buffer thing. I haven't looked into this too much aside from reading this article and comments, but I'm inclined to think that maybe the problem is with the CDNs rather than TWC or any ISP.
Basically, this listed IP block is part of a much larger allocation for Google. I don't know exactly what type of google service is hosted from it, but it isn't a commercial CDN.
Can you SSH into your router and do an `iptables --list` ? I'm thinking that implementation uses the L7 chain. If that's the case then it may be a hair bit quicker using my implementation. Also, the REJECT rule is a bit cleaner than just dropping the packet, which I also suspect to be the case with "Access Restriction" implementation.
I can do iptables under the firewall settings, but ... it took me a while to find my way through this setting and I know it works, I tested by streaming YouTube content on AppleTV. I am going to leave it as it is.
If this workaround gets popular, I wonder if my provider (Comcast) and others will catch up and throttle youtube directly.
I ran iftop and checked IPs with arin.net. I found a couple in the 206.111.0.0/16 range that didn't point to google or youtube. However, I originally had a handful of /24's, but the OP pointed out the entire /16 -- so I edited as such.
I also didn't find 173.194.55.0/24 in my testing. It's also a Google IP address, so I doubt it's causing any issues -- in fact, it may be the cause of some playback issues my wife is now having. (I think it may be their video ads, but have nothing to go on aside from getting "Playback Error" when an ad usually plays)
So you're basically looking for IPs allocated to Google (the arin.net part) that are not using very much bandwidth while you stream a youtube video (the iftop part)?
Given how big an ISP Time Warner is, wouldn't the CDN and/or Google eventually notice the slow responses from their end and start playing a game of cat-and-mouse rotating IP addresses in and out of service as proxies?
Noticed this from TWC somewhat recently as well when I realized that I was taking out my phone to watch YouTube videos more frequently (on 3G/4G). Now, I just keep my computers on a VPN as much as possible and there's a number of sites that just feel faster.
Is there any evidence TW is throttling versus these CDN servers you're being routed to simply being slow or overloaded?
I've noticed a change in YouTube buffering on FiOS the past few weeks as well. Other commenters here see it on Comcast. That may point to YouTube leaning more heavily on a CDN that can't handle the traffic (or some hop along the network to that CDN) rather than throttling by any one ISP.
I have TW... and I just tried what the guy suggested.
One hell of a difference. I'm pretty shocked that they're doing this. I always thought it was Youtube that was being slow. http://www.youtube.com/watch?v=CB8UADuVM5A is an accurate depiction of what I just experienced right now.
That blocking the CDN improved your loading speed doesn't provide evidence of throttling. It's equally plausible that the CDN is slow for everyone, whether you're a Time Warner subscriber or not. The way to verify this would be to connect to that CDN from different ISPs with similar routes and see if there appears to be a hard cap in one connection but not the other.
You can easily check if you have a 4g (LTE, HSPA+, WiMax, etc.) and checking the same youtube video in HD. It's truly night and day and really got me so mad at Roadrunner once I discovered that.
I have Verizon, as does a buddy of mine, and he and I have both been trading horror stories about how much YouTube sucks for the past few months.
I also applied the trick and now, magically, everything is quite a bit faster.
That said, while I'm not a network guy, this suggests that there's an issue with the YouTube CDN, not anything in particular with Time Warner or Verizon, unless they're doing something horrible relating to net neutrality.
My guess is just that there are a couple of CDN blocks that are preferred by the load balancers and they're saturated as a result, and blocking these IP ranges sends you to a less balanced block of CDNs.
I also don't know if there is any evidence. The cause can be many things. However, I can now verify without a doubt that this works. I turned the firewall rule on and off and tried multiple videos. When the rule is on, I can actually buffer an entire video like I could in the old days. With the rule off, it works, but is not so great.
I can only refer to anecdotal evidence I have seen on forums, Reddit, and from friends. That being said, it seems to be a stronger correlation with TWC rather than Verizon, but YMMV. Let me know if you uncover more details!
Prior to blocking these subnets, I would have significant pauses every few seconds using 360p. I just tested a few 1080p videos with no issues and without buffering, which is about as big of difference as possible.
How do I get Time Warner to start working in the first place? I bought a FreedomPop device just to get 4G wifi for the last month waiting for Time Warner to just fix our Internet (already had 3 separate appointments..). But glad to hear I'm going to have YouTube issues regardless..
Its too bad this breaks youtube-dl. I found a series of videos on youtube that revolutionized the way I do drywall and I can remember waiting forever for youtube-dl to grab the entire playlist.
The gentleman in the video is Laurier. I sent him a message on FB thanking him for the videos, he is extremely friendly. There is actually a neat story behind the videos. The current playlist is slightly different than the original set. A while back someone paid him to take the original series offline for six months (under the theory that they were too helpful). Laurier took him up on his offer and when he put them back online the playlist was slightly different but still remarkably helpful. I am an order of magnitude faster now when I rock a room. The biggest change for me was using the concrete trowel instead of the normal 4/6/12 inch mud knife. That being said I did pick up a number of tips from all of the videos. The only thing I cannot do is freehand cuts with a tape measure and a blade, I still use the T.
I would suggest watching the entire playlist once before your next project starts and then watch the relevant video before each step as a refresher. I used to dread any project that involved drywall. When I do "habitat for humantiy"-esque projects now I try my hardest to be on the rocking team.
EDIT:
If you are skeptical about watching all the videos my big ah-ha moment came when I understood "mud control." This is a nice example:
The DMCA modernized copyright law for the digital age, creating protections for network providers against infringement by their users, and making illegal circumvention of new digital copyright enforcement schemes. What part of this act do you think applies to throttling network connections, if that's what's happening here?
the videos/screenshots loads a lot slower after applying the fw rules. especially the thumbnails on the video page on the right side, takes forever to load. anyone else see the same?
This is going to be dependent on your location within the network. I'd never assume advice like this will work just anywhere on the planet, let alone within a large country. It certainly does provide a data point for the problem and a localized solution that can be generalized by those with more expertise. This author admits limited expertise with "Other people can dive into the complexity much better than I ever could, but that’s the overall theme."
Isn't it more likely that those CDN hosts are just overloaded or there are natural throughput limits somewhere between those networks? If TWC wanted to QoS YouTube, why not cover all the ranges?
I'm with TWC, and holy crap, now 1080p quality works just fine, whereas most of the time 720p would take forever to buffer. I'm on a 20/2 mbit plan, and it was ridiculous before this fix.
Wow, I'm surprised at the level of assumptions being made in this thread.
Guys, some networking 101:
* The route your traffic takes to get from point a to point b depends on your network/ISP/etc
* The CDN you use when accessing YouTube, et. al. depends on the route you take. The first/nearest CDN to you is (usually, depending on the CDN owner's configuration) the one that will be used.
* The fact that a video loads quickly on one ISP and slowly on another means absolutely, completely, totally NOTHING in and of itself.
To find out if the ISP is to blame or not, you must attempt to access the same CDN server from two different ISPs and see if you get the same problem. The latency will be different, but unless there is a massive bandwidth or latency bottleneck between two hops along either route, the overall bandwidth (for a large enough file) should be sufficient to deduce whether or not the problem is with your ISP or the CDN servers corresponding to the route your ISP is taking to contact Google's servers (the results need to be statistically significant taking into account margin of error and network conditions).
If the CDN is the problem, unless the CDN is actually owned by your ISP, your ISP is not to blame.
In fact, for traditional non-net-neutral throttling, it does not matter which/how many CDN IPs you block. Your ISP should (if they're doing it right) detect your connection to YouTube's subnet and throttle your data rates regardless of which CDN you use. The CDNs in the original article belong to Google/YouTube, not TW. As such, TW would throttle your connection on the way to Google's subnet, not at Google's subnet. They have no control over Google's subnet. The hops past TW's (or whatever ISP you use) servers are not under their control, cannot be bandwidth-throttled by them, and have nothing to do with net neutrality.
The real explanation is most likely poorly-balanced CDN servers. i.e. the traffic going to the CDNs is unfairly skewed towards one or more CDN servers, causing them to serve content to all users of all networks more slowly. By explicitly avoiding said CDNs which are slow on Google's end, you will use a different, less-pounded CDN that can serve your content faster.
Note that I am not even a TW user (Comcast here), but this lynch mob is getting out of control. I expect a higher understanding of basic network principles when I browse HN, and "I can't load YouTube quickly so this means my ISP is shaping my bandwidth, and I need not look for actual evidence to support this claim" does not qualify as such.
That said, yes, it is possible for a cunning ISP to shape your traffic by purposely mis-directing CDN selection, for example, making it so that all their users end up at the same exit (slow) node when contacting a YouTube IP as such effectively YouTube into serving all their content to all the ISP's users from the same CDN node(s), resulting in poor connection. The way to test this would be to map out the routes for packets sent all over, and search for statistically-significant routing anomalies when attempting to pass packets on to Google's network from within a certain ISP.
The CDN you use is often selected off a DNS response for many networks. An easy way to select a different CDN (that may adversely affect your browsing speed due to geo-origination!) would be to use a different DNS server (make sure to flush the DNS cache in your OS and in your browser). This is why it's not advised to use non-ISP DNS such as Google DNS, OpenDNS, etc) unless they're both a) anycast (basically CDN for DNS, your DNS query will go to the nearest geographic location to you) and b) have enough servers distributed around the country so that your anycast DNS request will be resolved near you, so that the CDN based off of DNS will also be physically near you. You can use namebench [0] by Google to query the fastest DNS servers, typically faster means closer as hops then physical distance are the biggest factors in DNS sp...
> The CDN you use when accessing YouTube, et. al. depends on the route you take. The first/nearest CDN to you is (usually, depending on the CDN owner's configuration) the one that will be used.
Just load a few videos in youtube with the chrome network tab from dev tools open, you'll very commonly see a CDN request returning a redirect to another CDN, 4-5 redirects isn't uncommon before the video plays.
Assuming that CDN selection is purely geographical or route based is just as poor an assumption as your accusing others of.
> Assuming that CDN selection is purely geographical or route based is just as poor an assumption as your accusing others of.
As you yourself quoted, I used the word "usually." That directly and explicitly implies "not purely."
The CDN you use depends on many factors. Nearness to your route/physical location is a big factor. The relative power/bandwidth of each CDN server is another factor (weighted distribution). Internal network factors also contribute to the decision, as does maintenance, BGP peering, random load distribution, and current network health/status.
I wrote my comment in response to your original comment, which was worded in a significantly harsher tone. I updated my comment with your edited quote.
Thanks for the detailed comment above. As I said earlier, I'm no networking guy! However, before posting I did test on a friend's Verizon FiOS connection, my own Verizon Mobile Hotspot, and also the various message boards I read complaining about speed appeared to be overwhelmingly TWC. I do understand that's not ideal proof. This was just intended to be a share of a quick fix.
Any suggestion to make my blog post more technically sound, I'm all ears! I can't seem to find a conclusion in all the HN comments except that "it could be a bunch of stuff going wrong", and to be honest, I don't have the expertise to find said conclusion.
The criticism was not leveled at you in particular, thank you for your willingness to revisit your assumptions. You need to test the connection to the same CDN node from a different ISP. Get the final URL for the video and try it on the other PC, and time the download for comparison. Make sure the CDN does not force a redirect to a different node.
You can get that kind of info from Chrome's "Resources" tab in the dev console (or the equivalent in whatever browser you are using). You should run the test several times to avoid warm/cold cache along the way. Should the results significantly differ, you should also note the traceroute/tracert results to the final hop.
Actually many "video cdns" rely on redirects at the HTTP level and don't work at the DNS layer at all. That's quite different to a normal CDN (where your comments do apply).
I'd like to correct your last paragraph. Most CDNs use anycast to send traffic to the closest POP they have to you. However, most implementations use DNS responses for the front-facing servers. Not many companies outside of CDNs have the need or capital to use anycast for normal web/end-user traffic.
There are several other scenarios where it can be your ISP or can cause significantly different timings between ISPs. A lot of ISPs offer a network internal forward caching system (CDN-like) so your traffic will appear to go directly from your ISP to the CDN. This is typically done with servers inside your ISPs network but with anycast routing so requests to the CDN outside of their network stay within it. I don't know if Google/YouTube does this, but I do know that Netflix does.
Edit: this is independent of the post, which shows nothing but a fundamental misunderstanding of what's actually going on and why. I'd be more interested to see if this was flash or html5 video, whether it was using rtmp(s) for flash or http streaming, what IPs it ended up hitting instead of those two blocks and whether a traceroute for those two blocks went through the same or a different peer from where it finally connected.
These are probably off-net cache servers for Google, which means that to save money on transit costs, Time Warner has installed special servers and Youtube references them directly for Comcast subscribers (lot's of things give this away, but I wouldn't be surprised if it was DNS based and they know based upon your resolver. Try switching over to a global but not eDNS based resolver and see what happens).
If that is the case, it's not unlikely that the off-net boxes are simply overloaded for people in this guy's usage area.
I tried adding the ip ranges in article and it rendered youtube inoperable for me. No matter what quality setting I used nothing would stream. Removed the rules and youtube streamed again, albeit slow as ever (still cant stream 720 & 1080)
I can't stand this ISP and I have no alternative available to me here. Talk about living in misery.
The inclusion of the 'preferred' and 'cache' bit are somewhat interesting.
I did find that if I block 208.117.0.0/16 as well as the other two mentions blocks (173.194.55.0/24, 206.111.0.0/16) then no youtube videos will load at all.
I would venture a guess that blocking the mentioned ranges is just forcing you to the 208.117.0.0/16 CDN.
135 comments
[ 4.8 ms ] story [ 172 ms ] threadAny new entrant has to build out a cable plant to reach subscribers and capture enough subscribers at a high enough density to make it worthwhile. The only company that's even trying at this point is Google.
2. Most of the larger markets are in densely populated cities, which makes laying infrastructure even more difficult (there's a reason that Verizon rolled out FiOS to suburban areas rather than urban areas).
3. If your 'value added' is something that the ISPs can easier undercut to drive you out of business (e.g. expanding bandwidth caps, increasing speeds), then your business proposition becomes even shakier.
[1] http://www.muninetworks.org/content/cable-monopoly-result-pr...
There was a young upstart I had high hopes for, but I was out of their area. They are http://www.widerangebroadband.net/ and their customer service was great, but unfortunately I'm just outside their area at the moment.
If anyone on Teksavvy has a workaround, please let me know. Thanks.
Edit: a bunch of people complaining on a google group thread about the same thing: https://productforums.google.com/forum/m/?fromgroups#!topic/...
$ whois 173.194.55.0
I won't include the whole output, but here is the link of the allocation: http://whois.arin.net/rest/net/NET-173-194-0-0-1
Basically, this listed IP block is part of a much larger allocation for Google. I don't know exactly what type of google service is hosted from it, but it isn't a commercial CDN.
> nslookup o-o---preferred---sn-mv-p5qe---v17---lscache1.c.youtube.com/
> Name: o-o.preferred.sn-mv-p5qe.v17.lscache1.c.youtube.com
> Address: 206.111.9.12
For those with tomato firmware: Administration -> Scripts -> Firewall
iptables -I FORWARD -s 192.168.1.0/24 -d 173.194.55.0/24 -j REJECT
iptables -I FORWARD -s 192.168.1.0/24 -d 206.111.0.0/16 -j REJECT
If this workaround gets popular, I wonder if my provider (Comcast) and others will catch up and throttle youtube directly.
So far so good.
I also didn't find 173.194.55.0/24 in my testing. It's also a Google IP address, so I doubt it's causing any issues -- in fact, it may be the cause of some playback issues my wife is now having. (I think it may be their video ads, but have nothing to go on aside from getting "Playback Error" when an ad usually plays)
I've noticed a change in YouTube buffering on FiOS the past few weeks as well. Other commenters here see it on Comcast. That may point to YouTube leaning more heavily on a CDN that can't handle the traffic (or some hop along the network to that CDN) rather than throttling by any one ISP.
One hell of a difference. I'm pretty shocked that they're doing this. I always thought it was Youtube that was being slow. http://www.youtube.com/watch?v=CB8UADuVM5A is an accurate depiction of what I just experienced right now.
I've never been able to watch anything in 1080 or 720 unless I want to go run an errand while it's loading.
After running these commands...1080 streaming like a boss.
I also applied the trick and now, magically, everything is quite a bit faster.
That said, while I'm not a network guy, this suggests that there's an issue with the YouTube CDN, not anything in particular with Time Warner or Verizon, unless they're doing something horrible relating to net neutrality.
My guess is just that there are a couple of CDN blocks that are preferred by the load balancers and they're saturated as a result, and blocking these IP ranges sends you to a less balanced block of CDNs.
I just temporarily blocked everything except 74.125.0.0/16 (google's home address), 173.194.55.0/24 and 206.111.0.0/16 (the CDN).
Youtube is plenty fast using the CDN. It can be slow to start because it sometimes tries other addresses first.
ipfw delete ____
where ____ is the id of the firewall entry.
The gentleman in the video is Laurier. I sent him a message on FB thanking him for the videos, he is extremely friendly. There is actually a neat story behind the videos. The current playlist is slightly different than the original set. A while back someone paid him to take the original series offline for six months (under the theory that they were too helpful). Laurier took him up on his offer and when he put them back online the playlist was slightly different but still remarkably helpful. I am an order of magnitude faster now when I rock a room. The biggest change for me was using the concrete trowel instead of the normal 4/6/12 inch mud knife. That being said I did pick up a number of tips from all of the videos. The only thing I cannot do is freehand cuts with a tape measure and a blade, I still use the T.
I would suggest watching the entire playlist once before your next project starts and then watch the relevant video before each step as a refresher. I used to dread any project that involved drywall. When I do "habitat for humantiy"-esque projects now I try my hardest to be on the rocking team.
EDIT:
If you are skeptical about watching all the videos my big ah-ha moment came when I understood "mud control." This is a nice example:
http://youtu.be/kPIIWGqzmRw?t=3m6s
http://ipvfoo.googlecode.com/
Guys, some networking 101:
* The route your traffic takes to get from point a to point b depends on your network/ISP/etc
* The CDN you use when accessing YouTube, et. al. depends on the route you take. The first/nearest CDN to you is (usually, depending on the CDN owner's configuration) the one that will be used.
* The fact that a video loads quickly on one ISP and slowly on another means absolutely, completely, totally NOTHING in and of itself.
To find out if the ISP is to blame or not, you must attempt to access the same CDN server from two different ISPs and see if you get the same problem. The latency will be different, but unless there is a massive bandwidth or latency bottleneck between two hops along either route, the overall bandwidth (for a large enough file) should be sufficient to deduce whether or not the problem is with your ISP or the CDN servers corresponding to the route your ISP is taking to contact Google's servers (the results need to be statistically significant taking into account margin of error and network conditions).
If the CDN is the problem, unless the CDN is actually owned by your ISP, your ISP is not to blame.
In fact, for traditional non-net-neutral throttling, it does not matter which/how many CDN IPs you block. Your ISP should (if they're doing it right) detect your connection to YouTube's subnet and throttle your data rates regardless of which CDN you use. The CDNs in the original article belong to Google/YouTube, not TW. As such, TW would throttle your connection on the way to Google's subnet, not at Google's subnet. They have no control over Google's subnet. The hops past TW's (or whatever ISP you use) servers are not under their control, cannot be bandwidth-throttled by them, and have nothing to do with net neutrality.
The real explanation is most likely poorly-balanced CDN servers. i.e. the traffic going to the CDNs is unfairly skewed towards one or more CDN servers, causing them to serve content to all users of all networks more slowly. By explicitly avoiding said CDNs which are slow on Google's end, you will use a different, less-pounded CDN that can serve your content faster.
Note that I am not even a TW user (Comcast here), but this lynch mob is getting out of control. I expect a higher understanding of basic network principles when I browse HN, and "I can't load YouTube quickly so this means my ISP is shaping my bandwidth, and I need not look for actual evidence to support this claim" does not qualify as such.
That said, yes, it is possible for a cunning ISP to shape your traffic by purposely mis-directing CDN selection, for example, making it so that all their users end up at the same exit (slow) node when contacting a YouTube IP as such effectively YouTube into serving all their content to all the ISP's users from the same CDN node(s), resulting in poor connection. The way to test this would be to map out the routes for packets sent all over, and search for statistically-significant routing anomalies when attempting to pass packets on to Google's network from within a certain ISP.
The CDN you use is often selected off a DNS response for many networks. An easy way to select a different CDN (that may adversely affect your browsing speed due to geo-origination!) would be to use a different DNS server (make sure to flush the DNS cache in your OS and in your browser). This is why it's not advised to use non-ISP DNS such as Google DNS, OpenDNS, etc) unless they're both a) anycast (basically CDN for DNS, your DNS query will go to the nearest geographic location to you) and b) have enough servers distributed around the country so that your anycast DNS request will be resolved near you, so that the CDN based off of DNS will also be physically near you. You can use namebench [0] by Google to query the fastest DNS servers, typically faster means closer as hops then physical distance are the biggest factors in DNS sp...
Just load a few videos in youtube with the chrome network tab from dev tools open, you'll very commonly see a CDN request returning a redirect to another CDN, 4-5 redirects isn't uncommon before the video plays.
Assuming that CDN selection is purely geographical or route based is just as poor an assumption as your accusing others of.
As you yourself quoted, I used the word "usually." That directly and explicitly implies "not purely."
The CDN you use depends on many factors. Nearness to your route/physical location is a big factor. The relative power/bandwidth of each CDN server is another factor (weighted distribution). Internal network factors also contribute to the decision, as does maintenance, BGP peering, random load distribution, and current network health/status.
Any suggestion to make my blog post more technically sound, I'm all ears! I can't seem to find a conclusion in all the HN comments except that "it could be a bunch of stuff going wrong", and to be honest, I don't have the expertise to find said conclusion.
You can get that kind of info from Chrome's "Resources" tab in the dev console (or the equivalent in whatever browser you are using). You should run the test several times to avoid warm/cold cache along the way. Should the results significantly differ, you should also note the traceroute/tracert results to the final hop.
You can try these ready-made tests from Glasnost, but they do not cover all cases: http://broadband.mpi-sws.org/transparency/bttest.php
Eg, The Jetstream CDN: http://www.jet-stream.com/
you + are = YOU'RE
There are several other scenarios where it can be your ISP or can cause significantly different timings between ISPs. A lot of ISPs offer a network internal forward caching system (CDN-like) so your traffic will appear to go directly from your ISP to the CDN. This is typically done with servers inside your ISPs network but with anycast routing so requests to the CDN outside of their network stay within it. I don't know if Google/YouTube does this, but I do know that Netflix does.
Edit: this is independent of the post, which shows nothing but a fundamental misunderstanding of what's actually going on and why. I'd be more interested to see if this was flash or html5 video, whether it was using rtmp(s) for flash or http streaming, what IPs it ended up hitting instead of those two blocks and whether a traceroute for those two blocks went through the same or a different peer from where it finally connected.
If that is the case, it's not unlikely that the off-net boxes are simply overloaded for people in this guy's usage area.
I tried adding the ip ranges in article and it rendered youtube inoperable for me. No matter what quality setting I used nothing would stream. Removed the rules and youtube streamed again, albeit slow as ever (still cant stream 720 & 1080)
I can't stand this ISP and I have no alternative available to me here. Talk about living in misery.
Interestingly for me the domain the videos are coming from are all of the same general form:
> r1.sn-jvhj5nu-p5qd.c.youtube.com (where the bit before c.youtube.com varies)
Where as the reddit discussion has domains of the form:
> o-o---preferred---sn-mv-p5qe---v17---lscache1.c.youtube.com
The inclusion of the 'preferred' and 'cache' bit are somewhat interesting.
I did find that if I block 208.117.0.0/16 as well as the other two mentions blocks (173.194.55.0/24, 206.111.0.0/16) then no youtube videos will load at all.
I would venture a guess that blocking the mentioned ranges is just forcing you to the 208.117.0.0/16 CDN.