YouTube is unbearable on 100Mbps VF/TC cable

Forums › One New Zealand (including Vodafone, WxC, Farmside) › YouTube is unbearable on 100Mbps VF/TC cable

1 | 2 | 3 | 4

1392 posts

Uber Geek

#829942 3-Jun-2013 09:37

freitasm: Sorry, but those DNS are wrong for Vodafone TelstraClear network, and I don't think malware has anything to do with this specific case.

i did some testing with tcl cable recently, after it was going really slow, and vodafone's dns servers seemed to work better than the tcl ones. they both had better google destinations, and higher hit rate / better average dns load time. (tcl was slightly faster some of the time, but much lower hit rate)

only problem was they were in auckland, whereas tcl were anycast.

google seemed to route via au/us for tcl. it shows a sydney hop, but latency over 200 msec, suggesting reverse path via the US.

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#829946 3-Jun-2013 09:51

mercutio: i did some testing with tcl cable recently, after it was going really slow, and vodafone's dns servers seemed to work better than the tcl ones. they both had better google destinations, and higher hit rate / better average dns load time. (tcl was slightly faster some of the time, but much lower hit rate)

only problem was they were in auckland, whereas tcl were anycast.

google seemed to route via au/us for tcl. it shows a sydney hop, but latency over 200 msec, suggesting reverse path via the US.

As TCL had their own Google cache, using the TCL DNS servers Google stays on net using 203.97.26.xxx addresses.

mercutio

1392 posts

Uber Geek

#829949 3-Jun-2013 10:04

sbiddle:
mercutio: i did some testing with tcl cable recently, after it was going really slow, and vodafone's dns servers seemed to work better than the tcl ones. they both had better google destinations, and higher hit rate / better average dns load time. (tcl was slightly faster some of the time, but much lower hit rate)

only problem was they were in auckland, whereas tcl were anycast.

google seemed to route via au/us for tcl. it shows a sydney hop, but latency over 200 msec, suggesting reverse path via the US.

As TCL had their own Google cache, using the TCL DNS servers Google stays on net using 203.97.26.xxx addresses.

well i was testing from 202.78.155.xxx and it seemed to work better. gmail still loads slow though :(

i was only using tcl cable temp, it was as bad as previous time using it temp. last time i found it was slower than normal 10 megabit adsl through another provider with similar latency (but akld with interleaving low)

although i don't remember the jitter being so high last time. international speed tests were terrible.

the whole "google cache" thing is complicated in that not all results will come from cache, and often if you look up random music videos or such they won't come from cache. whereas if you click on links from the main page they're more likely to. so it matters where the non local cache comes from too.

12ogue

2 posts

Wannabe Geek

#829958 3-Jun-2013 10:26

if the user is experiencing problems with web browsing, but not experiencing problems with torrents then the possibilities are narrowed to either DNS name resolution or his internet traffic being redirected through a compromised webserver via a malware payload. Eliminating the existence of malware is a best practice starting point for any browser based problem.

Using googles nambench application will determine whether or not the user is taking advantage of their connection and ip-address-name resolution performance.

freitasm

BDFL - Memuneh
79295 posts

Uber Geek

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#830076 3-Jun-2013 16:16

12ogue: if the user is experiencing problems with web browsing, but not experiencing problems with torrents then the possibilities are narrowed to either DNS name resolution or his internet traffic being redirected through a compromised webserver via a malware payload. Eliminating the existence of malware is a best practice starting point for any browser based problem.

Sure, but only if this one one localised instance. It affects almost every cable user, so I don't think it's the case.

Vodafone TelstraClear runs its own Google cache (and have for the last couple of years), and from time to time they do have problems. The Google cache is managed by Google and Vodafone TelstraClear has only to provide the bandwidth.

by using a third party DNS users actually ARE NOT HITTING THE CACHE.

MaxLV

656 posts

Ultimate Geek

#830236 3-Jun-2013 21:09

This has been an ONGOING problem for over six weeks nows! How long does it take your 'team' to investigate it and more importantly FIX the problem?

MaxLV

656 posts

Ultimate Geek

#830240 3-Jun-2013 21:16

mikerussellnz: Youtube issues drive me crazy. There is no point in posting a link to the video because the issue doesn't reproduce.

It is definitely slow the first them when they don't have it cached and then speeds up on subsequent loads because of the cache.

The cache alleviates the problem for common videos, but doesn't treat the cause which is the uplink to youtube is crap and anything that hasn't been cached (not popular things) crawls due to the same issues we had before the cache was installed.

It really sucks if you are not watching the popular stuff as everything is slow.

What REALLY sucks is that Vodafone is taking SO LONG to fix the problem! All we get is we'll investigate it and get it 'resolved' Six+ weeks is really long enough...

We (Vodafone customers) shouldn't have to use 'work arounds' to fix a Vodafone problem.

Trouble tickets dont help either. Ringing the help desk doesn't help coz they just say we DONT have any reported problems with You Tube or they dont know when it's going to be fixed...

Quic Broadband

Move to New Zealand's best fibre broadband service (affiliate link). Free setup code: R587125ERQ6VE. Note that to use Quic Broadband you must be comfortable with configuring your own router.

mercutio

1392 posts

Uber Geek

#830248 3-Jun-2013 21:36

it'd work so much better if google would just have a node in auckland., with their own backhaul.

jpollock

600 posts

Ultimate Geek

Trusted

#830319 4-Jun-2013 09:30

freitasm:
by using a third party DNS users actually ARE NOT HITTING THE CACHE.

Actually, on VF Cable they still might. VF cable's transparent proxy server seems to re-interpret the GET request in the header and re-perform the DNS lookup. At least that's what it used to do. I just assume that it still does.

This results in truly messed up stuff happening.

Let's say you've used a different DNS server and it says that www.google.com is 172.16.254.1.

Your browser creates a socket to 172.16.254.1 and sends

GET / HTTP/1.1 Host: www.google.com

The VF cable proxy server intercepts the request (it intercepts all port 80 traffic). In a misguided attempt to increase cache hits by reducing fanout, it looks at the Host entry and performs it's own DNS lookup. This results in the proxy ignoring 172.26.254.1 and going to what the _proxy_ thinks is the address for www.google.com.

This breaks all sorts of things, like testing, /etc/hosts, unblock-us, etc...

The only way to avoid it is to use a VPN or SSL.

---
http://blog.jason.pollock.ca

mercutio

1392 posts

Uber Geek

#830346 4-Jun-2013 10:33

jpollock:
freitasm:
by using a third party DNS users actually ARE NOT HITTING THE CACHE.

Actually, on VF Cable they still might. VF cable's transparent proxy server seems to re-interpret the GET request in the header and re-perform the DNS lookup. At least that's what it used to do. I just assume that it still does.

This results in truly messed up stuff happening.

Let's say you've used a different DNS server and it says that www.google.com is 172.16.254.1.

Your browser creates a socket to 172.16.254.1 and sends

GET / HTTP/1.1 Host: www.google.com

The VF cable proxy server intercepts the request (it intercepts all port 80 traffic). In a misguided attempt to increase cache hits by reducing fanout, it looks at the Host entry and performs it's own DNS lookup. This results in the proxy ignoring 172.26.254.1 and going to what the _proxy_ thinks is the address for www.google.com.

This breaks all sorts of things, like testing, /etc/hosts, unblock-us, etc...

The only way to avoid it is to use a VPN or SSL.

problem is that people seem to think it's the google cache having the issues, where lots of requests won't go via a local google cache as the data store is too small.

content regularly comes from much further away. as far as amsterdam when i've looked in the past, although now more seems to come from US.

youtube performance problems can be complex but having congestion to australia makes things way worse, because google will route to much furhter away via their own network, and any amount of packet loss can impact performance, the more the packet loss the bigger drop in performance.

MaxLV

656 posts

Ultimate Geek

#830768 4-Jun-2013 23:50

Sent an email to the support team tonight, and called the help desk.

Explained the problem, and was told not a Vodafone problem, as Vodafone dont host You Tube. Did appear to know or understand about caching!

Logged a Fault (TS 9335098)

Help desk person wanted remote access to my computer (I refused to allow that), on my home network. Initially she said I was using wireless access for internet access through my DLink router -> Modem. (I dont, it's ethernet connected)

Then *insisted that I load the following DNS on my computer, instead of the router: 203.97.78.43 and 203.97.78.44 even after I told her they were already loaded on the router. She said loading them on my computer (going through my router) would be a test to see if it resolved the problem. It didn't.

Two of the three You Tube videos I tried still stalled, and the last one wouldn't start at first, then stalled when buffering.

Email sent to CEO Russell Stanners complaining about the LONG time it's taking to have the You Tube issue resolved.

mercutio

1392 posts

Uber Geek

#830772 5-Jun-2013 00:11

MaxLV: Sent an email to the support team tonight, and called the help desk.

Explained the problem, and was told not a Vodafone problem, as Vodafone dont host You Tube. Did appear to know or understand about caching!

Logged a Fault (TS 9335098)

Help desk person wanted remote access to my computer (I refused to allow that), on my home network. Initially she said I was using wireless access for internet access through my DLink router -> Modem. (I dont, it's ethernet connected)

Then *insisted that I load the following DNS on my computer, instead of the router: 203.97.78.43 and 203.97.78.44 even after I told her they were already loaded on the router. She said loading them on my computer (going through my router) would be a test to see if it resolved the problem. It didn't.

Two of the three You Tube videos I tried still stalled, and the last one wouldn't start at first, then stalled when buffering.

Email sent to CEO Russell Stanners complaining about the LONG time it's taking to have the You Tube issue resolved.

i doubt it's the caching that's the problem. and it's true, they don't host youtube. if youtube want to deliver better performance in nz then they should host content locally and distribute it.

microsoft did it. why can't google?

mattbush

784 posts

Ultimate Geek
Inactive user

#830818 5-Jun-2013 09:11

Doesnt really matter what plan or ISP you are on ...most NZ internet users are throttled by lack of competition in international traffic.

As it costs ISP's it is clearly a place where throttling can save real cash.

It was widely reported that Vodafone paid over the "real value" for TCL and will be wanting a return.

Whether we are using Vodafone cable or UFB we still have the issue of international traffic...
IMO the biggest loss to NZ internet users was the loss of the competing undersea cable last year.

Another monopoly is Skytv where the result forces a lot of NZers to seek more current viewing from international sources, using more and more of the Southern Cross cable capacity.

jpollock

600 posts

Ultimate Geek

Trusted

#830826 5-Jun-2013 09:30

mattbush:
As it costs ISP's it is clearly a place where throttling can save real cash.

Actually, I think that's a fallacy. It is true in markets where accounts are unmetered, but NZ has metered accounts. ISPs charge per byte, and make a profit on every byte they deliver. Therefore, there should be no incentive to not deliver a byte.

The only issue would be if a prime time byte was more expensive than an off-peak byte (which it probably is). If that's the case, they should offer a discount on off-peak to shift discretionary traffic to overnight. Much better way to deal with it. As it stands, I have no incentive to delay any bulk transfers, so I don't.

As long as the incremental cost per byte is covered by the charge, there is no reason for the ISP to not act as the best bit pipe they can.

Which is why ISPs like SNAP are doing so well.

Jason

---
http://blog.jason.pollock.ca

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#830827 5-Jun-2013 09:37

mattbush:
It was widely reported that Vodafone paid over the "real value" for TCL and will be wanting a return.

Getting way OT here but Vodafone got a *very* good deal paying what they did. There are plenty in the industry who consider they got an absolute bargain and would have been happy to pay considerably more.

1 | 2 | 3 | 4