|
[ALL] Youtube streaming fixed by switching to non-Cox DNS serverI've been having major problems with Youtube videos loading lately. I'd have to pause them and let them load for lengthy periods of time. Someone mentioned that he fixed that problem by using openDNS servers, so I tried it, even though it made no sense to me. It seems to have done the trick. Why is it working better, and what is the problem with Cox's DNS? |
|
CoxTOC1 join:2007-05-15 Newport News, VA |
Re: [ALL] Youtube streaming fixed by switching to non-Cox DNS seI run my own DNS servers at my home and still have issues with Youtube Videos loading. It may be that openDNS is resolving to a different server farm than you were before which would be in line with what we've been saying. |
|
DaarkenRara Avises Premium Member join:2005-01-12 Southwest LA |
to deafcon22
Yeah, and I was thinking that it was on my end. |
|
dvd536as Mr. Pink as they come Premium Member join:2001-04-27 Phoenix, AZ |
to deafcon22
said by deafcon22:I've been having major problems with Youtube videos loading lately. I'd have to pause them and let them load for lengthy periods of time. Someone mentioned that he fixed that problem by using openDNS servers, so I tried it, even though it made no sense to me. It seems to have done the trick. Why is it working better, and what is the problem with Cox's DNS? If you want "Clean DNS servers" alternative to cox's, use 4.2.2.1 / 4.2.2.2 for no redirects! |
|
DaarkenRara Avises Premium Member join:2005-01-12 Southwest LA |
to deafcon22
As a followup, I also was having issues with youtube buffering all the time. However after changing the DNS to something else (opendns) the buffering ceased. Why would this change have this effect? I am paying for the 15mb package, I should not have had any buffering in the 1st place. |
|
|
I would imagine that YouTube is more than a single PC running out of somebody's basement That being said, by using a different DNS service the may resolve you to a different server in YouTube's server farm that is not affected by this performance issue. That being said, I don't believe this is a DNS issue but changing DNS providers gives you a random shot of reaching a YouTube server that is not having issues. |
|
|
to deafcon22
So what the heck can we do to ACTUALLY get a solution to this problem? Is there some way we can trick youtube's servers into routing us to different ones? I am tired of this crap. We can't exactly "contact youtube" about it. How would an issue like this even get raised? Maybe our friends at Cox could help us? |
|
ependergrass |
to deafcon22
A sidenote, yeah it's not Cox's problem.. but if 100,000 of your customers start complaining it becomes your problem and is in your best interest to try and resolve it. Certainly isn't getting any quieter around here. :P |
|
CoxTOC1 join:2007-05-15 Newport News, VA |
We've already attempted to contact YouTube and Google about this. |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ 1 edit |
to ependergrass
actually, cox is doing what they should...peer with the provider at the closest point possible for transit networking. rather than understand what is working and why, people would rather just complain. while this could have been alleviated by some of the cox techs on here doing a quick name resolution using nslookup or dig (where were you bbeesley ?), i have decided to take this on to alleviate all of the whining! now, this was done on one of my machines sitting behind my cox preferred connection in mesa arizona. i have no issues streaming any content whatsoever, and i'm not obsessed with the youtube so i never go there. at any rate, here are my results: With personal DNS server/4.2.2.2 -------------------------------- C:\Documents and Settings\tubbynet>nslookup Default Server: esx2k3-ad01.local.tubbynetworx.net Address: 192.168.189.42
> www.youtube.com Server: esx2k3-ad01.local.tubbynetworx.net Address: 192.168.189.42
Non-authoritative answer: Name: youtube.l.google.com Address: 208.65.153.253 Aliases: www.youtube.com
C:\Documents and Settings\tubbynet>nslookup Default Server: vnsc-bak.sys.gtei.net Address: 4.2.2.2
> www.youtube.com Server: vnsc-bak.sys.gtei.net Address: 4.2.2.2
Non-authoritative answer: Name: youtube.l.google.com Address: 208.65.153.253 Aliases: www.youtube.com
==========================================
With OpenDNS ----------------------- C:\Documents and Settings\tubbynet>nslookup Default Server: resolver1.opendns.com Address: 208.67.222.222
> www.youtube.com Server: resolver1.opendns.com Address: 208.67.222.222
Non-authoritative answer: Name: www.youtube.com Address: 208.67.216.132
============================================
With COX DNS ----------------------- C:\Documents and Settings\tubbynet>nslookup Default Server: ns2.ph.cox.net Address: 68.2.16.25
> www.youtube.com Server: ns2.ph.cox.net Address: 68.2.16.25
Non-authoritative answer: Name: youtube.l.google.com Address: 208.117.236.70 Aliases: www.youtube.com
i have my own dns servers in my house. i have msdns running for my active directory domain and then i have a ubuntu server running the latest version of bind slaved to that. i have my forward and reverse lookup zones to local.tubbynetworx.net and everything outside of my domain is either directed towards root servers or stored in cache. the top results are done when using my personal dns caching or using the level(3) any-casted 4.2.2.2 you can see they resolve to the same address (as they should since the any-cast and root servers try and narrow down your locality/as and direct traffic to the closest peering point [i know thats not *entirely* correct, but it serves to illustrate a point]). now, you can see that if i use the opendns servers, i receive a different result than the anycast results. again, if i change to the cox servers, my result changes again. now, this is what is being told you everyone complaining. it is not a cox problem, it is a cache/peer issue between cox and google, and if you resolve out to a different ip address, you will more than likely leave the cox transit network and hit the youtube cache engine that is peered with the isp of wherever the dns server is located. lets do some research before we start kvetching people! q. |
|
|
I've been using alternate DNS servers (4.2.2.1 and 4.2.2.2) for months and I still have the problem.
If its some kind of peering problem, could Cox change the routes and offload to another partner as a "test" to see if the issue clears up? |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
said by BillRoland:If its some kind of peering problem, could Cox change the routes and offload to another partner as a "test" to see if the issue clears up? it sounds logical, but more often than not it won't happen. i can't see any other provider with a peering location looking to take on the added stress of several million additional subs hitting their core infrastructure. i'm sure that cox *could* pay a transit provider (cogent, l(3), etc.) but it would add up and its more expensive than waiting on google to fix it. i also should have been more clear in my explanation, just because you are getting a different ip address resolution for youtube, doesn't mean it will work. in my case, the 4.2.2.2 server and my local dns probably hop off the cox network at the same point, giving the same ip address for youtube.com. however, depending on where that ip address gets peered back to with cox will determine your path through the interwebs and to the youtube servers. i'd have to spend a little more time looking at the routes and such and use my linux machines (since they provide udp pings rather than icmp, which is often deprioritized/blocked at most routers), but since i'm at work, it will have to wait until i get home and have some down time. bill, at the risk of sounding repetitive, i would just say change your dns to opendns if you really need your youtube fix. redirects are annoying, but i believe if you sign up you can opt out (or just not fat-finger a url to begin with ). q. |
|
|
to CoxTOC1
Well, I appreciate it. Thanks for trying at least Surely someone here can come up with some sort of workaround...... hmmmmm..... HOSTS file? lol. |
|
|
That would actually work quite well if you knew the IP of a YouTube server that isn't experiencing issues. |
|
|
to tubbynet
said by tubbynet:bill, at the risk of sounding repetitive, i would just say change your dns to opendns if you really need your youtube fix. redirects are annoying, but i believe if you sign up you can opt out (or just not fat-finger a url to begin with ). q. I'm not that big of a YouTube junky, but when I want to view a 2 minute video I don't really want to wait 20 minutes for it to buffer. This has been ongoing for months, I just want to know what the problem is here. If its Google, then fine maybe its time to find an alternative. |
|
Ikyuao join:2007-02-26 Wichita, KS |
to deafcon22
It's Google who bought the youtube out and own it, If it is very busy of network traffic at time then it is Google issue. I researched that whois command that says Google owns youtube.com web site. If you still having issues with youtube then take your complains up with google. |
|
dvd536as Mr. Pink as they come Premium Member join:2001-04-27 Phoenix, AZ |
to deafcon22
Doubtful this slow youtube issue[yes ive had it too] is a dns issue. once dns gets the ip, that is it for the dns servers. there is congestion somewhere along the way. |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ
1 recommendation |
to Ikyuao
said by Ikyuao: researched that whois command that says Google owns youtube.com web site thats really old news. google bought youtube what...two years ago... said by Ikyuao:If you still having issues with youtube then take your complains up with google. this is an issue that needs to be sorted between cox and youtube. but thanks as always for providing no useful information whatsoever. thanks for playing. q. |
|
Ikyuao join:2007-02-26 Wichita, KS |
Ikyuao
Member
2009-Jan-6 11:00 pm
Cox between and Google's youtube cannot be done to turn be help if issues of network traffic really exist of clogging within youtube web site of Google's stuff. |
|
|
|
to deafcon22
I'll take a look at this...... |
|
|
to deafcon22
Based on the symptoms, I assumed YouTube would answer DNS queries with different ip addresses based on the location of the request. That would explain why changing DNS servers would make a difference. What I see instead is that all DNS queries get the same set of responses, no matter where they come from. Instead, YouTube announces those ip blocks from different locations. So a traceroute to 208.65.153.253 leads to a west coast data center for west coast customers, and it leads to an east coast data center (looks like Miami, FL) for east coast customers.
deafcon22, can you confirm by posting up nslookup and tracert information from your PC? First, change your DNS server back to Cox. Then go to Start -> Run, type in "cmd", and hit enter. When the DOS window appears, type these commands:
nslookup www.youtube.com
nslookup www.youtube.com 208.67.222.222
The output will look like what tubbynet pasted, e.g.
Non-authoritative answer: Name: www.youtube.com Address: 208.67.216.132
After you have the replies, please trace the route to each like so:
tracert -d ip address
E.g.
tracert -d 208.67.216.132
It looks like this from Atlanta:
Tracing route to youtube.l.google.com [208.117.236.74] over a maximum of 30 hops:
... 6 2 ms 2 ms 2 ms 68.1.0.4 7 2 ms 2 ms 2 ms 68.1.0.29 8 3 ms 3 ms 3 ms 154.54.5.113 9 211 ms 58 ms 265 ms 154.54.5.38 10 117 ms 17 ms 206 ms 154.54.7.145 11 17 ms 17 ms 18 ms 154.54.24.234 12 31 ms 31 ms 31 ms 38.104.94.18 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 79 ms 79 ms 79 ms 208.117.236.74
68.1.0.29 is the last Cox router in the trace. We hand off to Cogent at 154.54.5.113, and that link looks great. Latency increases once the packets get into the Cogent network. |
|
JBT Premium Member join:2002-12-06 Odessa, FL |
JBT
Premium Member
2009-Jan-7 2:45 pm
Its been slow for me on both Cox and opendns DNs servers. It seems to come and go. Fast one hour slow the next. |
|
|
to CoxAbuse
said by CoxAbuse:Based on the symptoms, I assumed YouTube would answer DNS queries with different ip addresses based on the location of the request. That would explain why changing DNS servers would make a difference. What I see instead is that all DNS queries get the same set of responses, no matter where they come from. Instead, YouTube announces those ip blocks from different locations. I think the problem is caused by the YouTube DNS TTL settings, not by the IP answered by their DNS. It hurts that YouTube specifies a short 5 minute TTL. As Cox and other DNS servers dispense the popular site from their DNS cache, their remaining TTL just doesn't last very long before another DNS re-query is needed. Too bad also they have the same TTL on the CNAME for youtube.l.google.com. If you were lucky to request DNS after it had expired in cache, you'd get the full 300 seconds. Generally you'll probably get an average of 2 1/2 minutes worth of remaining TTL, then pause while DNS is queried again. The link below shows a raw DNS lookup through the root servers. It shows the 300 second (max) TTL. The result is shown in the 1st attached image. » www.dollardns.net/cgi-bi ··· y#reportThe next link shows a query through one of the Cox DNS servers. Use your browser's Reload button to watch the remaining TTL values decrease, that's what would be reported to your PC. This is shown by the 2nd attached image. » www.dollardns.net/cgi-bi ··· y#reportOr if you'd rather query 4.2.2.1, you'll see the same thing. This isn't Cox's problem. » www.dollardns.net/cgi-bi ··· y#reportThe problem seems to lie with YouTube / Google DNS. Cox and other DNS is functioning properly by caching and re-querying YouTube DNS as needed when TTL expires. A site like YouTube should have much longer DNS TTL because it takes a while to watch a video. |
|
|
Some Guy
Anon
2009-Jan-7 9:48 pm
You folks are so focused on one thing... dns to www.youtube.com. If you bothered to look at the entire user session, you would notice that viewing a video doesn't come from www.youtube.com, it fetches from specific hosts not mentioned in this thread at all.... for me the place the actual bulk file (video stream) comes from is: » v18.cache.googlevideo.comI've also seen it say things like "nyc-v105.nyc.youtube.com"... and 5 other subdomains... and hundreds of other host-names. How about you dig into your session and post some useful data about where your buffering bad stream is coming from? use tools like wget, curl, tcpdump... look for actual thruput... tcp retransmits... ping the hosts for packetloss... etc... find some common denominators... east coast, west coast only a certain range of hosts/ip's (on the google/youtube end) etc... Dwelling on the TTL time of DNS for the first packet of the complicated session is misguided effort. As an aside, I've noticed a huge icmp ttl range for possible video sources implying many many locations (colo's, cities, countries, etc)... but all the ip's that resolve from www.youtube.com are the same icmp ttl... implying one location where the web front end lives. ,Some Guy |
|
2 edits |
to deafcon22
Blazing speeds again as usual. Hey, I think I even edged out 128kbps ISDN! Time to find a new video site I guess. |
|
KrKHeavy Artillery For The Little Guy Premium Member join:2000-01-17 Tulsa, OK Netgear WNDR3700v2 Zoom 5341J
|
to deafcon22
Actually I think it is a Cox issue. The second I switched from DSL to Cox my problems with streaming video began... at Youtube and other sites.
It's so bad that even the ads fail a lot... (Very unusual-- normally the ads stream fine and the video you WANT to watch stalls so you have to reload and watch the ads again--- infuriating...) at least with Cox even the ads die. |
|
KrK |
to tubbynet
said by tubbynet:it is not a cox problem, it is a cache/peer issue between cox and google, Explain how that makes it not Cox's problem, however. |
|
1 recommendation |
to deafcon22
Cox Engineers and Google Engineers are in contact. We're working this...... |
|
|
said by charterengr:Cox Engineers and Google Engineers are in contact. We're working this...... That's very good news, thanks charterengr |
|
|
to charterengr
Been getting worst the past 2 weeks here in the New England Market, havent saw it relaly before, just the past 2 weeks. Hopefully it is resolved soon, been having multiple ppl complain about it in RI and CT. |
|