YouTube is unusable with the fastest connection. Is Cox responsible for this?

There are a bunch of threads on this issue. I do believe Cox participates in the Google's caching program. They use Content Delivery Servers (CDN) by Akamai on Cox's network. The problem seems to be Cox limits/throttles/etc the connection between their customers and this network. So the very system designed to improve throughput to Cox customers actually causes a issue. 

Thanks for the additional information on what you've heard about Cox's CDN.  I've contacted our business representative to ask more questions about the problem.  I can't imagine us signing a multi-year fiber agreement if their connection to the CDN is either throttled or just overloaded.  

So you have Cox Business Fiber? This should be interesting. Please keep us informed how it goes. There are ALOT of people with the same issue.

My company is currently waiting on a proposal for Cox Fiber.  We're also getting one from Level 3 who is in the same building as us.  Before we sign any new deals with Cox, I want answers first.

It was perfect after work, but give it enough time and sure enough it starts to fail again.  I decided to do a tracert

Thats not a tracert to the Youtube content, just the server that hosts the website itself. Instead while watching the video press F12 and debug mode should come up then click on the network tab. How you get the info from there depends on your browser but your looking for the Host. Should look something like:

 r16---sn-ab5e6nl7.googlevideo.com

The problem is a tracert won't show the problem because it's not a latency issue, its a throughput issue. It would be like if someone downgraded your internet, its not going to change your latency. 

You're right, I should have known that.  Here's the tracert to the actual content this time, since I'm unable to watch YouTube content... So 68.6.11.186 is a Cox IP address then it times out.  Clearly that isn't good for streaming, right? 

C:\>tracert r7---sn-mv-a5m6.googlevideo.com

Tracing route to r7.sn-mv-a5m6.googlevideo.com [209.116.150.210]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.X.X
2 8 ms 8 ms 8 ms 10.162.0.1
3 9 ms 9 ms 10 ms 68.6.11.186
4 * * * Request timed out.
5 27 ms 9 ms 11 ms fed1dsrj01-xe130.0.rd.sd.cox.net [68.6.8.0]
6 17 ms 15 ms 14 ms langbbrj01-ae2.rd.la.cox.net [68.1.1.14]
7 37 ms 39 ms 38 ms 216.156.65.25.ptr.us.xo.net [216.156.65.25]
8 45 ms 37 ms 41 ms 209.116.150.210

Trace complete.

I also did the same tracert from my work's cable connection, also with Cox.  Notice how it times out on the 4th hop, just like my home connection?  

C:\>tracert r7---sn-mv-a5m6.googlevideo.com

Tracing route to r7.sn-mv-a5m6.googlevideo.com [209.116.150.210]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.X.X
2 8 ms 7 ms 8 ms 10.172.0.1
3 8 ms 10 ms 16 ms fed1sysc02-gex0919.sd.sd.cox.net [68.6.11.110]
4 * * * Request timed out.
5 8 ms 9 ms 15 ms fed1dsrj02-xe130.0.rd.sd.cox.net [68.6.8.4]
6 18 ms 15 ms 17 ms langbbrj01-ae2.rd.la.cox.net [68.1.1.14]
7 36 ms 37 ms 38 ms 216.156.65.25.ptr.us.xo.net [216.156.65.25]
8 37 ms 39 ms 42 ms 209.116.150.210

Trace complete.

Hop 4 is just ICMP de-prioritization. Another words its not traffic effecting. If it was you wouldn't see 14-17ms by hop 6. You see that in most tracert. Its nothing to worry about.

Also it looks like your going through the XO backbone. Thats completely different then all the other tracert I have seen.   Or you sure you have the correct content link? I try to sort all the network paths by size and look for the one thats atleast 2+MB. Here is a example.

Tracing route to r20.sn-ab5l6n7l.googlevideo.com [74.125.172.121]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms router.asus.com [192.168.1.1]
2 8 ms 7 ms 10 ms 10.2.120.1
3 9 ms 10 ms 9 ms wwcksysc01-gex0103000.ri.ri.cox.net [68.9.8.13]
4 8 ms 11 ms 8 ms ip98-190-33-32.ri.ri.cox.net [98.190.33.32]
5 8 ms 18 ms 9 ms provdsrj01-ae3.0.rd.ri.cox.net [98.190.33.20]
6 17 ms 24 ms 13 ms 68.1.5.157
7 25 ms 14 ms 15 ms 68.105.31.118  (Cox)
8 18 ms 14 ms 15 ms 209.85.248.180 (Google)
9 17 ms 15 ms 17 ms 72.14.238.233
10 36 ms 16 ms 15 ms 209.85.244.131
11 18 ms 14 ms 18 ms 74.125.172.121
Trace complete.

 Also note neither Tracert shows Youtube content running of a CDN. If you did you would only see 4-5 hops and see Cox all the way to endpoint. Were you having difficulty streaming this video particular video that "r7---sn-mv-a5m6.googlevideo.com" points to?

Yes, I was having trouble streaming a video where that points to.  The problem is happening right now with any YouTube video it seems.  I was chatting with a Cox rep, who said they do not participate in Google's Peering & Caching programs.  He opened up a ticket for me.  My original setup I was using Google's Open DNS servers, 8.8.8.8 and 8.8.4.4 but in the troubleshooting process I changed them to Open DNS, which is what they are at the moment.  If I use a VPN service to connect elsewhere, I'm able to stream over the slower VPN connection.

This one, https://www.youtube.com/watch?v=SAbgZpaTgvo for example, can't stream HD right now.  It's coming from r7---sn-mv-abl.googlevideo.com.  This one is actually WAY better than it was, but it still can't stream 720p without buffering.  An hour earlier, 720p wouldn't play at all, 480p would skip and 360p would play.  When I first made this post, only 140p would play with buffering, usually seems like during peak times.

I took a video screen capture to show exactly what I'm talking about.  Interestingly enough, I did several tracerts and it switched from nlevel.com to level3.com.

[Updated]  https://www.youtube.com/watch?v=k8Yx2JRI7hg

I've done some more tracert testing, and it seems the route changes quite often.  When it's on XO, it is almost unusable, even without HD.  You can see in this video, it is hitting XO's network and is unwatchable:  https://www.youtube.com/watch?v=J2NU5a5tp9s

Worse than level3 and nlevel.

C:\>tracert r7---sn-mv-ab5l.googlevideo.com

Tracing route to r7.sn-mv-ab5l.googlevideo.com [206.111.13.178]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.X.X
2 11 ms 9 ms 15 ms 10.162.0.1
3 9 ms 7 ms 10 ms ip68-6-12-94.sd.sd.cox.net [68.6.12.94]
4 * * * Request timed out.
5 13 ms 7 ms 10 ms fed1sysc01-gex0901.sd.sd.cox.net [68.6.8.100]
6 38 ms 40 ms 40 ms 68.1.2.109
7 68 ms 67 ms 66 ms 207.86.210.9
8 107 ms 108 ms 107 ms 207.88.13.242.ptr.us.xo.net [207.88.13.242]
9 113 ms 103 ms 107 ms te-4-0-0.rar3.atlanta-ga.us.xo.net [207.88.12.1]

10 110 ms 117 ms 117 ms te-11-0-0.rar3.washington-dc.us.xo.net [207.88.1
2.10]
11 104 ms 106 ms 104 ms ae0d0.cir1.ashburn-va.us.xo.net [207.88.13.61]
12 104 ms 104 ms 104 ms 206.111.13.194.ptr.us.xo.net [206.111.13.194]
13 104 ms 104 ms 106 ms 206.111.13.178.ptr.us.xo.net [206.111.13.178]

I don't know what they "participate" in but this tracert seems to be ** evidence that they do. This is just one tracert, I have others showing traces for actual content links. So unless something changed in the last couple of weeks..

Tracing route to youtube.com [174.76.229.118] (Note, This is from RI)
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 <b>174.76.229.118</b>
Trace complete.

As for your data, mine doesn't seem to match yours. First my network source points to "r19---sn-ab5l6n76.googlevideo.com" and a tracert is;

Tracing route to r20.sn-ab5l6n7l.googlevideo.com [74.125.172.121]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router.asus.com [192.168.1.1]
2 8 ms 7 ms 10 ms 10.2.120.1
3 9 ms 10 ms 9 ms wwcksysc01-gex0103000.ri.ri.cox.net [68.9.8.13]

4 8 ms 11 ms 8 ms ip98-190-33-32.ri.ri.cox.net [98.190.33.32]
5 8 ms 18 ms 9 ms provdsrj01-ae3.0.rd.ri.cox.net [98.190.33.20]
6 17 ms 24 ms 13 ms 68.1.5.157
7 25 ms 14 ms 15 ms 68.105.31.118
8 18 ms 14 ms 15 ms 209.85.248.180
9 17 ms 15 ms 17 ms 72.14.238.233
10 36 ms 16 ms 15 ms 209.85.244.131
11 18 ms 14 ms 18 ms 74.125.172.121

Trace complete.

First the movie runs fine for me in 720p, so that rules out a video problem. Next, when I looked at my streaming i notice it was downloading blocks of 2MB each every second just about. Normally I would see longer pauses and then larger downloads. I think these quick small downloads is a sign of when the problem ISN'T happening. Can you concur? Also, notice both traces leave Cox by hop 8, but in my tracert, it's a direct peer onto a Google IP. In your tracert your going over a XO backbone. This could possibly be just the way traffic is routed in your area (since your other side of country as me) but its should be noted incase you see a pattern. 

 It should also be noted that the problem doesn't happen to me anymore. For about a month now I notice non of the local servers are used and everything goes over the backbone, to my satisfaction. So I think we both had peering issues, but yours is a issue with XO. If your thinking of getting a Fiber Business account I would ask them to investigate congestion between them and XO.

This is a very good watch. Its publically available, I found it just by searching Cox and CDN.  While it's mostly about Cox's Contour product, I think it gives some good insite on Cox's implementation of CDN technology. 

 http://www.youtube.com/watch?v=Jz5XiA8euYQ

I wanted to provide an update.  I was able to get this issue pushed up to the network engineers and they have confirmed that Cox does infact participate in Google Global Cache.  They have also said that there was a capacity issue with XO and that it was resolved a few days ago.  I was going to perform some more tests last night, but I did not have any problems streaming at all or much time to do further testing.

If I'm using Google's Open DNS, I would figure that I would be routed to the GCC inside of Cox's network.  Instead my traffic was going to the east coast (I'm in San Diego) over XO's network. I plan to work with the engineers to try and figure out why my YouTube traffic isn't being directed to the GCC inside of Cox's network.

Thank you very much for sharing this with us.   Do you happen to have any tickets number or anything we can reference as edvidence that Cox does participate in CDN services with Youtube.

No, but I will be monitoring the problem and working with their NOC to see why traffic wasn't going to the local GCC.  I'll leave the notifications on this thread.  If you do have issues, post the tracert and nslookups to the google content server here.