[ALL] Youtube HD. Please post Pings/Tracert/Data (Long Post)
THIS IS NOT JUST A COX ISSUE. But it also effects Cox customers, thus I post here.
Problem: Intermittent inability to stream Youtube at higher resolutions. I have seen this reported with different ISPs, using different DNS, different computers, across a wide range of geographical location, from RI to AZ.
Symptoms: Sometimes certain resolutions will be greyed out, other times they will be selectable, but not obtainable. When selected, the "Change Quality" Icon (Gear) will spin until; it stops with no change of resolution, it spins indefinitely, a Youtube HTML error shows on screen (experienced but did not obtain screenshot). Frequent IP changes, sometimes as often as every 5 seconds, likly load balancing but the frequency seems unusual. When using Google DNS, IPs given seem to be registered via ARIN to Cox.
Details: As the problem was occuring I started collecting the fallowing Data. During the collection of that data, the symptoms changed, fixed itself, then recurred several times. When changing DNS I kept my PC DNS to DHCP and changed it on my WAN settings. After each change I would reboot router, reset adapter and flush the DNS cache. Bypass was not possible at time, but will do that next.
Question: Who else is having this problem? If possible, please respond with general location, IP obtained when Pinging youtube.com (no www), and what DNS you are using, along with any other thoughts you may have. First I ping and Tracert Youtube using Google DNS PING Youtube using Google DNS Pinging youtube.com [174.76.229.118] with 32 bytes of data: Reply from 174.76.229.118: bytes=32 time=8ms TTL=59 Reply from 174.76.229.118: bytes=32 time=8ms TTL=59 Reply from 174.76.229.118: bytes=32 time=8ms TTL=59 Reply from 174.76.229.118: bytes=32 time=9ms TTL=59 Ping statistics for 174.76.229.118: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 8ms, Maximum = 9ms, Average = 8ms
Tracing route to youtube.com [174.76.229.118] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms router.asus.com [192.168.1.1] 2 12 ms 10 ms 8 ms x.x.x.x 3 7 ms 7 ms 8 ms wwcksysc02-gex0203000.ri.ri.cox.net [68.9.9.13] 4 9 ms 9 ms 10 ms ip98-190-33-21.ri.ri.cox.net [98.190.33.21] 5 9 ms 10 ms 7 ms provdsrj01-ae3.0.rd.ri.cox.net [98.190.33.20] 6 14 ms 9 ms 8 ms 174.76.229.118 Trace complete.
That seems like a short trip, and only 1 IP off of Cox? Huh? So I ARIN that IP ARIN 174.76.229.118 Network NetRange 174.76.224.0 - 174.76.239.255 CIDR 174.76.224.0/20 Name NETBLK-AT-INT-174-76-224-0 Handle NET-174-76-224-0-1 Parent CXA (NET-174-64-0-0-1) Net Type Reassigned Origin AS Customer Cox Communications (C02489149) Registration Date 2010-05-07 Last Updated 2010-05-07 Customer Name Cox Communications Handle C02489149 Street 1400 Lake Hearn Dr City Atlanta State/Province GA Postal Code 30319 Country US Registration Date 2010-05-07 Last Updated 2011-03-19
So, the final hop of Youtube...belongs to Cox? What range of IP? Google DNS Dig Non-authoritative answer: Name: youtube.com Addresses: 2607:f8b0:400d:c04::5b 174.76.229.119 174.76.229.99 174.76.229.104 174.76.229.114 174.76.229.84 174.76.229.123 174.76.229.98 174.76.229.88 174.76.229.108 174.76.229.103 174.76.229.118 174.76.229.89 174.76.229.109 174.76.229.94 174.76.229.113 174.76.229.93
Ok Odd, the whole range of IP, according to Google DNS and ARIN, belong to Cox? What if we check Cox DNS? Cox DNS Dig (68.105.28.12) Non-authoritative answer: Name: youtube.com Addresses: 2607:f8b0:400e:c04::88 74.125.224.134 74.125.224.135 74.125.224.136 74.125.224.137 74.125.224.142 74.125.224.128 74.125.224.129 74.125.224.130 74.125.224.131 74.125.224.132 74.125.224.133
And then tracert? Tracing route to youtube.com [74.125.224.133] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms router.asus.com [192.168.1.1] 2 7 ms 8 ms 7 ms x.x.x.x 3 9 ms 9 ms 7 ms wwcksysc02-gex0203000.ri.ri.cox.net [68.9.9.13] 4 9 ms 9 ms 12 ms ip98-190-33-38.ri.ri.cox.net [98.190.33.38] 5 7 ms 7 ms 7 ms provdsrj02-ae3.0.rd.ri.cox.net [98.190.33.26] 6 14 ms 13 ms 13 ms 68.1.5.157 7 14 ms 16 ms 14 ms 72.14.222.224 8 15 ms 14 ms 14 ms 209.85.248.178 9 15 ms 14 ms 22 ms 209.85.252.242 10 20 ms 21 ms 19 ms 209.85.249.11 11 29 ms 26 ms 28 ms 66.249.95.229 12 35 ms 36 ms 35 ms 216.239.48.40 13 88 ms 88 ms 109 ms 72.14.239.81 14 90 ms 89 ms 102 ms 64.233.174.189 15 88 ms 87 ms 88 ms 209.85.250.251 16 88 ms 88 ms 87 ms lax02s20-in-f5.1e100.net [74.125.224.133]
What I find odd, is the extreme difference in download speed/times of various content, on YouTube. For me mainly music videos.
Using Video DownloadHelper Firefox Addon, downloading 720p/1080p Music Videos approx. 50-100+ MB I find that many videos will fully download in a few seconds to a few minutes, while others can take up to 1 hour, for a video of approx the same filesize, downloaded at the same time.
This behavior is fairly new.
If you want to experience this you will need to install the latest beta version, as YouTube keeps changing the source code, in an attempt to disable downloads. YouTube is apparently using an algorithm to constantly change the source code. I am currently using DownloadHelper version 4.9.21a1 »www.downloadhelper.net/i ··· 4.9.21a1
==================================================== Here are the pings and tracert you requested, using Google DNS 8.8.8.8 & 8.8.4.4
Pinging youtube.com [74.125.224.137] with 32 bytes of data: Reply from 74.125.224.137: bytes=32 time=27ms TTL=53 Reply from 74.125.224.137: bytes=32 time=29ms TTL=53 Reply from 74.125.224.137: bytes=32 time=50ms TTL=53 Reply from 74.125.224.137: bytes=32 time=24ms TTL=53
Ping statistics for 74.125.224.137: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 24ms, Maximum = 50ms, Average = 32ms
Pinging youtube.com [74.125.224.137] with 32 bytes of data: Reply from 74.125.224.137: bytes=32 time=25ms TTL=53 Reply from 74.125.224.137: bytes=32 time=31ms TTL=53 Reply from 74.125.224.137: bytes=32 time=26ms TTL=53 Reply from 74.125.224.137: bytes=32 time=29ms TTL=53
Ping statistics for 74.125.224.137: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 25ms, Maximum = 31ms, Average = 27ms
Tracing route to youtube.com [74.125.224.137] over a maximum of 30 hops:
1 4 ms 4 ms 2 ms 192.168.0.1 2 12 ms 12 ms 13 ms 10.39.120.1 3 13 ms 19 ms 13 ms 172.21.0.128 4 21 ms 17 ms 16 ms 70.169.73.90 5 15 ms 14 ms 13 ms chnddsrj01-ae2.0.rd.ph.cox.net [70.169.76.229] 6 * 27 ms 31 ms langbprj02-ae2.rd.la.cox.net [68.1.1.19] 7 49 ms 45 ms 46 ms 72.14.215.221 8 31 ms 27 ms 32 ms 209.85.248.185 9 27 ms 27 ms 28 ms 209.85.250.251 10 27 ms 24 ms 36 ms lax02s20-in-f9.1e100.net [74.125.224.137]
Tracing route to youtube.com [74.125.224.137] over a maximum of 30 hops:
1 4 ms 3 ms 3 ms 192.168.0.1 2 15 ms 12 ms 12 ms 10.39.120.1 3 15 ms 11 ms 13 ms 172.21.0.128 4 25 ms 19 ms 19 ms 70.169.73.90 5 12 ms 12 ms 13 ms chnddsrj01-ae2.0.rd.ph.cox.net [70.169.76.229] 6 * * * Request timed out. 7 50 ms 44 ms 47 ms 72.14.215.221 8 44 ms 75 ms 48 ms 209.85.248.185 9 27 ms 33 ms 27 ms 209.85.250.251 10 31 ms 22 ms 29 ms lax02s20-in-f9.1e100.net [74.125.224.137]
Tracing route to youtube.com [74.125.224.137] over a maximum of 30 hops:
1 5 ms 4 ms 3 ms 192.168.0.1 2 24 ms 18 ms 10 ms 10.39.120.1 3 14 ms 13 ms 12 ms 172.21.0.128 4 12 ms 23 ms 24 ms 70.169.73.90 5 14 ms 12 ms 38 ms chnddsrj01-ae2.0.rd.ph.cox.net [70.169.76.229] 6 * * * Request timed out. 7 47 ms 45 ms 45 ms 72.14.215.221 8 27 ms 29 ms 21 ms 209.85.248.185 9 26 ms 30 ms 26 ms 209.85.250.251 10 25 ms 24 ms 25 ms lax02s20-in-f9.1e100.net [74.125.224.137]
Thank you for the data. I assume your coming out of Phoenix AZ? Could you do a nslookup to show what IP your Google DNS is showing? Seems its showing what my local Cox DNS is showing. A DNS propagation issue?
Also, since my first suspect would be the router (because who knows right?) so I bypassed that. This is direct from a Windows 7 desktop, CAT6 direct into Cisco DPQ3212. Disabled NIC, reboot modem, disable IPv6, set IPv4 DHCP IP and Static DNS > 8.8.8.8 & 8.8.4.4 Waited for Dial Tone to return, enable NIC, wait for new IP, flush DNS cache and then the fallowing data:
Windows IP Configuration Ethernet adapter Local Area Connection 2: Connection-specific DNS Suffix . : ri.cox.net IPv4 Address. . . . . . . . . . . : 68.228.15x.xx (Available to Cox Tech) Subnet Mask . . . . . . . . . . . : 255.255.254.0 Default Gateway . . . . . . . . . : 68.228.15x.x ::Edit:: Removed other adapter info for simplicity.
Pinging youtube.com [174.76.229.119] with 32 bytes of data: Reply from 174.76.229.119: bytes=32 time=9ms TTL=59 Reply from 174.76.229.119: bytes=32 time=9ms TTL=59 Reply from 174.76.229.119: bytes=32 time=8ms TTL=59 Reply from 174.76.229.119: bytes=32 time=8ms TTL=59 Ping statistics for 174.76.229.119: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 8ms, Maximum = 9ms, Average = 8ms
Tracing route to youtube.com [174.76.229.119] over a maximum of 30 hops: 1 7 ms 7 ms 8 ms x.x.x.x 2 7 ms 6 ms 7 ms wwcksysc02-gex0203000.ri.ri.cox.net [68.9.9.13] 3 7 ms 8 ms 7 ms ip98-190-33-38.ri.ri.cox.net [98.190.33.38] 4 * 8 ms 8 ms provdsrj02-ae3.0.rd.ri.cox.net [98.190.33.26] 5 8 ms 8 ms 8 ms provdsrj01-ae0.0.rd.ri.cox.net [68.1.0.45] 6 7 ms 8 ms 8 ms 174.76.229.119 Trace complete.
I suspect this has something to do with DNS caching at the ISP. But then why would Cox IP's show when using Google DNS but not Cox DNS? That seems backwards right? This seems so odd I feel I MUST be missing something. Kind of hope I don't look like a fool, but I can't explain it. Could someone with Dig skills greater then mine see what is going on?
Wanting to fact check myself, thinking maybe it was a PC issue, I used some 3rd party tools at »www.dnsstuff.com/ I noticed when I dug using their tool to 8.8.8.8 I got the typical 74.125.227.x. Ok, so maybe it is my desktop. I connect a Windows 7 laptop direct to modem, reboot/etc using DHCP IP and DNS. Pings 74.125.227.x. as normal since Cox DNS. Change to Google DNS, reboot/etc, I Ping 174.76.229.x. I can copy/paste it but at this point it's kind of redundant. So thats two separate computers, direct to my modem getting 174.76.229.x using Google DNS while on Cox. Im starting to feel less foolish and more specious.
I know Google's DNS isn't just 1 server, but I am not exactly sure how it works. What dictates which server I get a domain results from when querying 8.8.8.8?
On thing to keep in mind too is that the videos are not served by youtube.com, they are served from a long name (don't remember what they are) something like vid1-tc4-r139.video.youtube.com
When you ping youtube.com, your just getting the main webpage, not the video server(s).
Thank you, I imagined something like that. Hmm, then that further complicates what I learned last night. DrDrew was kind enough to inform ISP DNS cache is likely the cause of the IP ARIN to Cox on the last hope of the trace to youtube.com when using Google DNS.
So I did a little reading and found that ISP DNS caching in hand with CDN servers works similar to your PC's site cache, or Temporary Files. When you go to request a site, that request is first sent to the DNS cache where it looks up if the site is available on the content delivery network(CDN) server. If not it downloads a copy of that site into it's memory at the same time you download the site. These servers are actually a array in large distribution centers located right on the edge's of the ISP network, before the backbone. The theory being anything downloaded from these servers, since closer, will be faster, and save the ISP from having to use up bandwidth on the backbone. So it's a Win/Win. Youtube pays the CDN for any content delivered that way, and CDN pays the ISP to have the servers on their network. That is why the IP belonged to Cox, because it's their network, just their network inside being hosted by the CDN. Also, Google (and thus youtube) has a Global Cache that may work as a added layer, and one they can directly control with load balancing. Its actually really fascinating and plays a huge role in the internet, and I just scratched the Iceberg with that description.
So long story short I think the ARIN was a wild goose chase, especially since by what Chris says, that IP doesn't even belong to the content servers, but location of Youtube's main hosting site .Not sure how that ties in, but I think there is still a performance problem going on somewhere that I am missing. I have heard too many friends come to me in the last week or two with this problem asking for my help for it just to be a fluke.
What makes the issue so annoying to troubleshoot is that problem is very intermittent, and that intermittence varies from person to person and from movie to movie. So not only can I access one youtube video quite fine, and someone else can't, but I may have problems with all my videos some moments, while someone else doesn't have any problems with any Videos. Still other's don't seem to be effected at all. I think this has to do with the complex layering of redundancy and load balancing that goes on with such a HUGE site as Youtube. I am going to try to make a Thread on Google's forums, see if it gets any hits. Reason I haven't up to now is because there doesn't seem to be too much activity over there.
So does anyone have any theories/data on what they think is going on? For me this isn't just academic, I cant watch my Youtubes, Yarrr!
Probably what you need to do is at a command prompt (possibly being run as an administrator) is to run the "netstat" or "netstat -b" command to see what network connections are currently active while you are streaming a video. Ideally, the only thing you are doing is watching the video so it's less confusing.
That would at least show where the actual video is being streamed from. Actually, just now I ran the Resource Monitor in Windows 7 and looked at the Network Tab and selected Firefox. Added the bytes recv column and started playing a video. For this specific video, everything was coming from 173.194.24.179 (a Google IP) and had this tracert:
>tracert 173.194.24.179
Tracing route to 173.194.24.179 over a maximum of 30 hops
1 1 ms 1 ms 1 ms 192.168.1.1
2 6 ms 9 ms 7 ms 10.2.0.1
3 5 ms 9 ms 9 ms COX-68-12-10-90-static.coxinet.net [68.12.10.90]
4 15 ms 10 ms 7 ms COX-68-12-8-50-static.coxinet.net [68.12.8.50]
5 19 ms 9 ms 9 ms 68.1.5.135
6 12 ms 17 ms 11 ms 72.14.212.237
7 * * * Request timed out.
8 18 ms 16 ms 19 ms 72.14.233.64
9 12 ms 18 ms 19 ms 72.14.232.187
10 12 ms 9 ms 9 ms 173.194.24.179
Trace complete.
Doing a tracert to youtube.com was completely different after the 6th hop.
ARS did a recent article on this (apolgies for those that are already all over this). Not saying any of this has anything to do with your particular issues...but it's an interesting read. »arstechnica.com/informat ··· e-video/
@Mark Good advice. I didn't think to do that in the first place because I wasn't looking for something PC specific since, but that does at least isolate the source. Here is a small sample of the netstat while streaming about 30seconds of Youtube content at 480p. This is when the problem was only occurring moderately. I could stream 720p, but slow to buffer and unable to do 1080p, which i normally can with ease. Is it normal for it to keep opening multiple sources for the same content? Also, note the 174.76.229.x range. Last, Mark, are you, or were you, experiencing the problem when that tracert was done?
TCP 192.168.1.169:11882 174.76.229.104:http ESTABLISHED [chrome.exe] TCP 192.168.1.169:11883 lga15s28-in-f11:https ESTABLISHED [chrome.exe] TCP 192.168.1.169:11885 lga15s34-in-f12:https ESTABLISHED [chrome.exe] TCP 192.168.1.169:11886 174.76.229.104:http ESTABLISHED [chrome.exe] TCP 192.168.1.169:11887 174.76.229.113:http ESTABLISHED [chrome.exe] TCP 192.168.1.169:11890 lga15s28-in-f25:http ESTABLISHED [chrome.exe] TCP 192.168.1.169:11891 174.76.229.84:http ESTABLISHED [chrome.exe] TCP 192.168.1.169:11892 174.76.229.94:http ESTABLISHED [chrome.exe] TCP 192.168.1.169:11893 174.76.229.94:http ESTABLISHED [System] TCP 192.168.1.169:11894 174.76.229.79:http ESTABLISHED [System] TCP 192.168.1.169:11895 174.76.229.79:http ESTABLISHED [System] TCP 192.168.1.169:11896 174.76.229.79:http ESTABLISHED
Any idea what the " lga15s28-in-f25" is? I see similar domains(?) through out the Netstat. Maybe Ads? I have Adblocker though, and they seemed to occur when using MSIE too which I don't have Ad Blocker on.
@ JoshuaCA Good read. Just did a quick glance so far, but do you suspect some kind of issue between one of the CDN and Cox the way Cognet has issue with Verizon? I ask because RI is usually a good example of what stuff will be like across other markets. Probably because the competition is so rough up here, Cox seems to bring their A game. Or maybe something else. ::shrug::
@BryanInPHX I haden't use Namebench in a while, and when I finished, it was showing google.com as "hijacked" Did this happen with you? Seems its a bug with some routers and how they tunnel the DNS request and/or if the namebench App has old IP's. Either way it came back as my current DNS is the fastest.
Another odd thing I noticed is some videos are coming up as HTML5 even though I have disabled the HTML5 trial. I was taking part in it some time ago, but that was one of the first thing I tried disabling when having the issue. Why would Youtube be showing me HTML5 if not part of the trial? Are some video's on youtube just encoded that way?
::Edit:: It "possible" that I might have stumbled apon something. I was reading the google thread below about people getting locked in HTML5. The fix it to go to »www.youtube.com/html5 join the trial, then quit the trial. I don't know if it did anything to help with my problem, but it fixed the HTML5 glitch and it seems Youtube is running faster. It may just be happening to run faster right now though. Only time will tell.
I'd may suggest is try run dual NIC cards and distribution the DNS spend out in splits as you plugs both the two wires to the router device between and your computer and also may suggest to try tweak the IE pipe connections from 4 pipes to 8 pipes or 16 pipes to see if any it helps.
my DNS client distribution been configured over the two NIC links in splits mode.
Could you provide some technical detail and some reference material? I actually have a dual NIC on my board, but I don't see how increasing the bandwidth from PC to LAN will help when that is not where the bottleneck is. This isn't something specific to me, I have been tracking this issue over 4 other forums, probably a total of 10 or so threads. If you read back I think you will find my data adequate in ruling out any local issues. Any bottleneck here would at least cause streaming issues with other media too, not just youtube. I appreciate your enthusiasm in your rather....elaborate solutions, but I would rather not complicate the issue without good reason, but I welcome your retort.
Could you provide some technical detail and some reference material? I actually have a dual NIC on my board, but I don't see how increasing the bandwidth from PC to LAN will help when that is not where the bottleneck is. This isn't something specific to me, I have been tracking this issue over 4 other forums, probably a total of 10 or so threads. If you read back I think you will find my data adequate in ruling out any local issues. Any bottleneck here would at least cause streaming issues with other media too, not just youtube. I appreciate your enthusiasm in your rather....elaborate solutions, but I would rather not complicate the issue without good reason, but I welcome your retort.
In windows 7, go to control panel items then go to network and sharing center then just do configure the two NIC for DNS splitting in the distribution as long as it is active where you are plugged the two wire between your computer and your router or combo gateway cable modem.
Ikyuaoki, I am shocked that you would think "I" would have a gateway. ::grin:: Also I mentioned earlier in the post what I have for a modem. A DPQ3212.
But ok, I will bite. How would one "then just do configure the two NIC for DNS splitting in the distribution" Are you talking about ICS? Setting up a bridge? Even if I doubled my connection rate from PC to Modem, that would not speed up my connection from modem to youtube. It is a interesting idea, but why do you think it is relevant to my OP?
Sorry I just don't fallow. Could you give me a technical reference or white sheet to fallow? If not then please allow this thread to continue on topic. Thanks.
Sorry I just don't fallow. Could you give me a technical reference or white sheet to fallow? If not then please allow this thread to continue on topic. Thanks.
well, in network sharing center panel if you are plugged the two lines it should be showing the active appears in connection status then just click each the interface. put two DNS into split, by simple put primary DNS in #one NIC and secondary DNS in #two NIC to do acts the DNS split in the communication sense.
if you can't follow, then i'm done here on your thread.
As a update, I tried enabling Windows firewall and enacting a custom firewall rule blocking IP 174.76.224.0/20. It didn't make a difference and It didn't seem to work, but I admit its my first time even enabling Windows Firewall, so I am not a expert. I will try my router's firewall, see if that has greater effect.
FWIW I've been noticing lately that youtube videos will just stop playing, presumably while waiting to buffer. It's been rather unreliable for the last few weeks. So, I think it is credible that it could be ISP wide. I've been hearing other similar complaints from users of other ISP's. Fortunately I'm not a heavy youtube user.
So I was unable to even watch Youtube in 420p, direct to modem this morning. So I switched to DHCP DNS and its still bad, but i am going to give it 24hr. Anyone else in RI able to confirm this?
Yah I've stopped using Cox DNS servers... it seems they are redirecting all Youtube traffic to their own local server farms. I'd guess Cox does't have enough servers to host Youtube reliably for their customers. After switching to use non-Cox DNS servers all my Youtube troubles disappeared.
I'd guess they are hosting multiple server farms for various Google services. Quite a few ISPs do this to reduce peering bandwidth with other carriers.
The first lookup is using Cox DNS servers, the 2nd lookup is a non-Cox DNS server.
The odd part is my symtom seems to be the exact opposite, I am being redirect to the Cox server farm using the 174.x.x.x IP space when using Google DNS but 74.x.x. when using Cox DNS. The problem seems to occur either way. I think that is because the only thing that is actually changing is the response from the domain server when pinging the domain, the session seen in netstat when downloading content is using 174.x.x.x either way, so I have to conclude, for me, that BOTH DNS are redirecting to Cox CDN's servers. I think your general theory of Cox not accounting for the amount of traffic in "some" areas is why some people are having the problem, and some aren't. Probably some area's don't have the Youtube server farms, and some do, but have enough bandwidth to match the lesser bandwidth demand. I think this is why I see it in RI and there seems a high concentration in PHX which is one of Cox bigger market and maybe higher concentration of user per square mile? In PHX its because you have alot of people. In RI it's because we don't have a lot of square miles? LOL
Thats my working theory and it seems to fit the evidence. Could AZTech or a Cox employee care to confirm that Cox is making use of Youtube CDN servers in some markets? I think that would be a good start.
This has been covered by many "Tech" reporting sites.. The issue is bandwidth contention at the traffic exchange and peering points between cox and google/youtube. Neither side wants to spend more money to upgrade the connection between the two.
No amount of changing DNS , bypassing your router, clearing history/cache, changing operating systems, devices, etc will change that. The only thing that will help (as proven by other users on verizon) is using a different provider other than COX that doesn't have an overloaded traffic exchange with google/youtube..
The first step of solving any problem is first finding the problem. At this point I am looking for Cox to publicly confirm that which the data seems to apply, that Cox has Youtube content servers on their network space. Is this technically accurate?
(sigh) nickphx has a point, you can change it by different ISP providers. Cox does not need have to confirm it for your issues. trying finding the cox out for fault is pointless and quite seems be meaningless at this point for your issue. you can do is change the different ISP providers other than Cox.
What Cox does or does not need to confirm is best left for Cox to decide. What I post is up to me, and what I can post is up to the Moderator of this forum. I am asking a simple question with a likely complex answer, but I feel it is a legitimate question for me to ask as a Cox customer. If you personally feel this thread is a waste of your time, then please feel free not to be a part of it. If you feel it is not a waste, then feel free to add constructive input. Thank you.