Hi, ex-youtube video eng here. (also posted this as a comment on the blog post)
A while ago YouTube put together a speed information page that you could use to check out your download speeds as well as compare to other isps in your area:
I'm also on Time Warner, and my graph shows wild inconsistencies - sometimes it spikes up to much faster than others, sometimes it's way below the average speed, and it also shows that Time Warner is the slowest provider out of all of the NYC area ISPs.
I wish it was easier to switch to another provider out here.
Thanks for the my_speed link. When I run the test video contained at 720p, I consistently get outstanding video with no streaming pauses.
However, if I switch to another video (say a Google IO 2012 presentation), I get long pauses within the video constantly. 5-10 seconds of video, with 3-5 second pauses. In short, the test is hardly representative of my normal YouTube results.
I'm on FiOS, and my graph also shows wild inconsistencies, sometimes spiking up much faster than others, sometimes way below every other line in the graph for multiple days. I'm leaning towards this not being an ISP problem at all until there's more evidence.
I'm also on time warner NYC. The funny thing is my 30 mbps wideband is consistently ~30 mbps from almost everywhere. Torrents and downloads consistently max out my bandwidth (even during peak hours) and most sites load just as quickly as my work's speedy connection. Youtube is the only site I have issues with.
Interestingly enough, the video embedded in that page doesn't load at all when I have the two subnets listed in the article blocked. Everything else on YT loads fine, and that particular video loads fine if the subnets are unblocked. I'm guessing this is a unique experience based on the other comments.
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.
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.
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.
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.
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!
Weird, I could have used this thread four days ago. I cancelled my newly purchased 18mb/s uverse account because youtube (and only youtube) was taking 20+ minutes to download 5 minute videos. I switched over the Brighthouse (division of time warner I believe) because I still had an account and everything was fine. When I contacted AT&T, all they did was tell me that youtube was to blame and that I could purchase a tech support contract. I declined :). There's a massive thread on the topic over here: http://forums.att.com/t5/Features-and-How-To/Hey-At-amp-T-St...
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.
Measuring YouTube Quality of Experience for Users in Residential ISPs*
Deep Medhi [email protected] University of Missouri–Kansas City
February 2013
*Joint work with Parikshit Juluri (UMKC), Louis Plissonneau
(Orange Labs, France), and Yong Zeng (UMKC)
This actually helped a lot, as soon as videos started, the grey buffering meter (that sits behind the red play meter) would shoot over to the other side ... I was actually astonished.
Alas there was one horrible side effect. Videos took forever to start playing, and thumbnails for other videos on the screen (in the related videos section and other image assets) would not load until afte the video started playing.
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 speed, though a shitty DNS server will obviously skew those results.
> 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.
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'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.
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.
This could actually be due to DNS, rather than anything particular to that edge-cache/CDN. Resolvers that aren't actually close to you (network-wise) could cause problems like this, or TWC partitioning their network in a way that causes geographically diverse locations to get lumped together, etc. In essence you'd be talking to edge-caches on the wrong edge, so to speak.
To test: try a different DNS resolver, and see if you start getting faster video loads. If you're using TWC's local resolver, try 8.8.8.8 (run by Google); if you're using Google's already try the local resolver and/or OpenDNS (208.67.222.222).
If that does work as well, I'd recommend it over the heavy-handed approach of blocking arbitrary netblocks. Especially since that second netblock listed isn't owned by Google, and so you could be collaterally blocking other content that you still want.
(Disclaimer: I work for Google, but in Ads, not anything network or YouTube related).
I'm a TWC customer, and I used to have consistently horrible YouTube speeds. I eventually got sick of it and read somewhere to try different DNS, as you suggested. I switched from TWC's DNS to OpenDNS probably around a year ago, and YouTube did become faster. It's less consistent now, sometimes loading nicely and sometimes slowly. youtube.com/my_speed claims I'm averaging 7.6 Mbps vs. the average 5.2 for my ISP and 6.4 for the region. I see occasional traffic from 206.111.0.0/16, but it seems to be coming largely from 74.125.0.0/16 and 173.194.0.0/16.
Based on the discussion here at HN, I've updated the title in my blog post to call out "ISPs" generically and not TWC specifically. I felt I did my due diligence sufficiently before crafting my title, but as we know, a sample of one is not statistically significant!
Fios user here. I'm travelling right now so I can't test. But youtube has been consistently poor for months now. Even 240p is unusable in many cases.
Interestingly, I get consistently the best performance from 360p and 1080 with the rest giving absurdly unusable streaming speeds. Not great, but servicable if i go get some coffee while buffers. I wonder if the different resolutions are being served up from different CDNs?
Anybody try this on fios and find improvements?
(btw my wife gets better streaming performance than i do on youtube from various video streaming sites in asia and i'd bet a dollar i live within 10 miles of a google data center. The google forums are on fire with complaints)
I have noticed some serious throttling on from Comcast for Youtube as of late.
I can tell because directly viewing youtube gets throttled about 2min in (so they pick up on it about 2min in, regardless of where I start watching the video). If I VPN to work I can watch the same video no throttle, and still have bandwidth to spare.
It's the same bottle neck, Comcast, and work is down the road from me on their own dedicated fiber, it's adding 4 hops and it actually runs faster. (and I checked the IPs, I'm connecting to the same youtube servers as far as I can tell)
interesting that using google's dns server isn't going to make things faster. I also noticed youtube was slower for me recently, and I do use google's dns. Let me switch back to my isp's dns and see if it makes any difference.
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.
I had a similar problem, it looked like it wouldn't stream, but it actually just took a long time to start, once it did, it buffered very very quickly. but that delay was a killer. had to delete the rules after a couple of videos
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.
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.
[+] [-] tensafefrogs|13 years ago|reply
A while ago YouTube put together a speed information page that you could use to check out your download speeds as well as compare to other isps in your area:
http://www.youtube.com/my_speed
I'm also on Time Warner, and my graph shows wild inconsistencies - sometimes it spikes up to much faster than others, sometimes it's way below the average speed, and it also shows that Time Warner is the slowest provider out of all of the NYC area ISPs.
I wish it was easier to switch to another provider out here.
[+] [-] ryanhuff|13 years ago|reply
However, if I switch to another video (say a Google IO 2012 presentation), I get long pauses within the video constantly. 5-10 seconds of video, with 3-5 second pauses. In short, the test is hardly representative of my normal YouTube results.
[+] [-] raldi|13 years ago|reply
"The test video will show you your streaming information in real time (look next to "Streaming HTTP")."
Uh, where? I don't see that anywhere, and Ctrl-F "streaming" doesn't find it, either.
[+] [-] dangrossman|13 years ago|reply
[+] [-] rm999|13 years ago|reply
[+] [-] fyrabanks|13 years ago|reply
[+] [-] tensafefrogs|13 years ago|reply
[+] [-] mikecane|13 years ago|reply
[+] [-] cloudwalking|13 years ago|reply
[+] [-] MikeCapone|13 years ago|reply
If anyone on Teksavvy has a workaround, please let me know. Thanks.
[+] [-] dangrossman|13 years ago|reply
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.
[+] [-] clicks|13 years ago|reply
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.
[+] [-] sharms|13 years ago|reply
[+] [-] sounds|13 years ago|reply
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.
[+] [-] Apreche|13 years ago|reply
[+] [-] Reebz|13 years ago|reply
[+] [-] kbar13|13 years ago|reply
[+] [-] wcchandler|13 years ago|reply
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
[+] [-] lor3nzo|13 years ago|reply
[+] [-] altcognito|13 years ago|reply
[+] [-] LAMike|13 years ago|reply
[+] [-] rhizome|13 years ago|reply
[+] [-] trotsky|13 years ago|reply
https://www.nanog.org/meetings/nanog57/presentations/Tuesday...
tool you can run to measure your own performance with jitter and dropouts and which caches your're being routed to:
https://code.google.com/p/pytomo/
For a bunch of internet enthusiasts y'all sure don't understand much about the world beyond your aws cluster.
[+] [-] trustfundbaby|13 years ago|reply
Alas there was one horrible side effect. Videos took forever to start playing, and thumbnails for other videos on the screen (in the related videos section and other image assets) would not load until afte the video started playing.
so close :\
[+] [-] ComputerGuru|13 years ago|reply
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 speed, though a shitty DNS server will obviously skew those results.
0: https://code.google.com/p/namebench/
[+] [-] mbell|13 years ago|reply
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.
[+] [-] alexgartrell|13 years ago|reply
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.
[+] [-] ismarc|13 years ago|reply
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.
[+] [-] shmerl|13 years ago|reply
[+] [-] epistasis|13 years ago|reply
[+] [-] kellysutton|13 years ago|reply
[+] [-] rcthompson|13 years ago|reply
[+] [-] rorrr|13 years ago|reply
[+] [-] aba_sababa|13 years ago|reply
..let's just say that if the author ever comes to Brooklyn, he will not leave sober. This is incredible.
[+] [-] EricBurnett|13 years ago|reply
To test: try a different DNS resolver, and see if you start getting faster video loads. If you're using TWC's local resolver, try 8.8.8.8 (run by Google); if you're using Google's already try the local resolver and/or OpenDNS (208.67.222.222).
If that does work as well, I'd recommend it over the heavy-handed approach of blocking arbitrary netblocks. Especially since that second netblock listed isn't owned by Google, and so you could be collaterally blocking other content that you still want.
(Disclaimer: I work for Google, but in Ads, not anything network or YouTube related).
[+] [-] georgefox|13 years ago|reply
[+] [-] driverdan|13 years ago|reply
[+] [-] Reebz|13 years ago|reply
[+] [-] bane|13 years ago|reply
Interestingly, I get consistently the best performance from 360p and 1080 with the rest giving absurdly unusable streaming speeds. Not great, but servicable if i go get some coffee while buffers. I wonder if the different resolutions are being served up from different CDNs?
Anybody try this on fios and find improvements?
(btw my wife gets better streaming performance than i do on youtube from various video streaming sites in asia and i'd bet a dollar i live within 10 miles of a google data center. The google forums are on fire with complaints)
[+] [-] megaframe|13 years ago|reply
I have noticed some serious throttling on from Comcast for Youtube as of late.
I can tell because directly viewing youtube gets throttled about 2min in (so they pick up on it about 2min in, regardless of where I start watching the video). If I VPN to work I can watch the same video no throttle, and still have bandwidth to spare.
It's the same bottle neck, Comcast, and work is down the road from me on their own dedicated fiber, it's adding 4 hops and it actually runs faster. (and I checked the IPs, I'm connecting to the same youtube servers as far as I can tell)
[+] [-] codva|13 years ago|reply
[+] [-] nl|13 years ago|reply
The performance I was getting was terrible - much much worse than any other device on my home network.
Turned out it was because I was using the Google DNS servers for the TV, and that was screwing it up.
The ABC iView app uses Akamai, which doesn't use the new DNS extensions to pass through the location of the client computer.
Changed DNS server and everything was good again.
[+] [-] chii|13 years ago|reply
[+] [-] Aco-|13 years ago|reply
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.
[+] [-] trustfundbaby|13 years ago|reply
[+] [-] Reebz|13 years ago|reply
[+] [-] mbell|13 years ago|reply
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.
[+] [-] pragone|13 years ago|reply
[+] [-] birken|13 years ago|reply
$ 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.
[+] [-] mbell|13 years ago|reply
> 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