TR Forums

cynan wrote:

Are you referring to how the DNS server you are connected through routes ISP requests? Or are you referring to the selection of the DNS server by the local router? I know that I get more consistent performance if I turn off dynamic DNS in my router and enter the DNS servers of my ISP directly. How connection requests are routed beyond that is up to my ISP (which usually does a better job than my relatively cheapo router).

I'm not really sure what you mean by all this, but DNS simply like a phone book that associates names with numbers. E.g.I query my DNS server to discover that http://www.netflix.com translates to 54.225.69.109. But, it's even more complex than that, because of anycast (your IP for netflix.com could be different). But we'll keep it simple.

Dynamic DNS in your router probably refers to a dynamic name service like no-ip.biz or dyndns.org, in which you can get a name associated with a non-static IP. It works because the router lets the dynamic name service know when your dynamic IP changes, so they can update the records.

So that shouldn't have any effect on anything, and if you mean that the DNS servers you get through DHCP are somehow different than what you think are your ISP's DNS servers, you'd better have a talk with them because that's really strange.

And yes, once you are past names (and thus DNS) and into the realm of numeric IPs, you have no control of the routing. In fact, at that point, your ISP has very little control of the routing.

Airmantharp wrote:

cynan wrote:

Are you referring to how the DNS server you are connected through routes ISP requests? Or are you referring to the selection of the DNS server by the local router? I know that I get more consistent performance if I turn off dynamic DNS in my router and enter the DNS servers of my ISP directly. How connection requests are routed beyond that is up to my ISP (which usually does a better job than my relatively cheapo router).

In theory, both. It's DNS as it relates to the end-point, so 'where' the DNS routes come from is really only a matter of discussion if it's being adjusted as part of the troubleshooting process.

And on that note, what about OpenDNS?

I haven't ran it for a while, but when I've run a DNS benchmark software, which ranks DNS servers available to you (or at least in your area) by their ability to resolve (and how quickly) a list of 50 or so popular domain names. My ISP's DNS servers consistently came out on top of both OpenDNS and Google.

UnfriendlyFire wrote:

Mediacom also implemented a 250GB data cap last year.

OK?

UnfriendlyFire wrote:

I would like to hear your explanation of my ISP's reasoning.

Huh? How would I know?

UnfriendlyFire wrote:

I'm interpreting the data cap and the unusually slow Youtube download speeds as an attempt to reduce load on their network without telling the customers that they're going to have to downgrade connection speeds and still charge the same.

Except that:
1) You already stated that the slowdowns occur during non-peak times.
2) Either they want to make money from the overages or they don't.

Admittedly it's possible that they are trying to make money from overages while simultaneously throttling to prevent them, but that doesn't actually make any sense.

I'm not defending Mediacom. Maybe they are money-grubbing bastards. All I am saying is that your test didn't even remotely prove the null hypothesis and it is extremely unlikely that they are throttling "Youtube" because "Youtube" is a gigantic CDN. Yes, maybe they are being shady using their DNS to deliberately point you to an overwhelmed server, but you shouldn't even start pointing fingers like that until you're tried the simplest things first: Did you use Google's public DNS 8.8.8.8 ? See if that solves your issue.

cynan wrote:

I haven't ran it for a while, but when I've run a DNS benchmark software, which ranks DNS servers available to you (or at least in your area) by their ability to resolve (and how quickly) a list of 50 or so popular domain names. My ISP's DNS servers consistently came out on top of both OpenDNS and Google.

ICK! NO!

That's bad.

In the modern age of the CDN, the question isn't how fast it resolves a name (which at this point is only a question of latency between you and the DNS server and thus I'm sure your ISP would win), but whether the numeric addresses it gives you are the appropriate ones! If I return an IP for a Netflix Content Server in China to you that isn't good at all, even if it only took 0.1ms to respond to the DNS request!

Glorious wrote:

cynan wrote:

I haven't ran it for a while, but when I've run a DNS benchmark software, which ranks DNS servers available to you (or at least in your area) by their ability to resolve (and how quickly) a list of 50 or so popular domain names. My ISP's DNS servers consistently came out on top of both OpenDNS and Google.

ICK! NO!

That's bad.

In the modern age of the CDN, the question isn't how fast it resolves a name (which at this point is only a question of latency between you and the DNS server and thus I'm sure your ISP would win), but whether the numeric addresses it gives you are the appropriate ones! If I return an IP for a Netflix Content Server in China to you that isn't good at all, even if it only took 0.1ms to respond to the DNS request!

Well, the benchmark is a bit more complicated that merely factoring resolving speed. But I don't remember exactly what it takes into account. You can peruse the link if interested. However, I've found, for my own experience, good correlation between the results of this benchmark and overall performance. Occasionally, though, the top ranked DNS server doesn't perform so well, so it's not perfect. In the end, after using this software, and browsing testimony from others on my ISP, I've come to the conclusion that using my ISPs DNS servers will most likely give me the best performance. Until I run into issues with webpages loading right away, etc, I'll just stick with it.

cynan wrote:

Well, the benchmark is a bit more complicated that merely factoring resolving speed. But I don't remember exactly what it takes into account. You can peruse the link if interested. However, I've found, for my own experience, good correlation between the results of this benchmark and overall performance. Occasionally, though, the top ranked DNS server doesn't perform so well, so it's not perfect. In the end, after using this software, and browsing testimony from others on my ISP, I've come to the conclusion that using my ISPs DNS servers will most likely give me the best performance. Until I run into issues with webpages loading right away, etc, I'll just stick with it.

:Groan: Grc.com strikes again.

Again, unless your DNS server sucks spectacularly (in which event you should just use 8.8.8.8 ), who cares?

Here in real-life, I'm not waiting for names to resolve, however, I'm frequently waiting for cdn.* or ad-serv.* to serve my content (or, grumble, my ads). Hence, the relevant question is what CDN servers I am getting. This was actually one of the trenchant criticisms of Google's SPDY: Yeah, it's good and all, but we're not really waiting because of deficiencies in HTTP but rather for ads. i.e. we're ad-server-limited.

I don't want fast resolution, I want correct resolution. Because, as I said, shaving 15ms off of my DNS queries isn't helping me, at all, if it only resolves to CDNs located in China.

Heck, I'm surprised I didn't mention this:

Right now, on my work internet connection, cdn.arstechnica.net is completely and utterly broken. This, in turn, breaks the site. It takes minutes to load arstechnica.com because their CDN hosts their CSS, which the site presentation depends upon. And, of course, once it finally times out I get to read the site without the CSS, which is obviously a mess.

So, unless I want to wait for minutes, I have to look at about:source to actually read anything. Yay.

This is why the appropriate CDN resolution is essential. The speed of the DNS lookup?, not so much!

Glorious wrote:

:Groan: Grc.com strikes again.

Again, unless your DNS server sucks spectacularly (in which event you should just use 8.8.8.8 ), who cares?

Here in real-life, I'm not waiting for names to resolve, however, I'm frequently waiting for cdn.* or ad-serv.* to serve my content (or, grumble, my ads). Hence, the relevant question is what CDN servers I am getting. This was actually one of the trenchant criticisms of Google's SPDY: Yeah, it's good and all, but we're not really waiting because of deficiencies in HTTP but rather for ads. i.e. we're ad-server-limited.

I don't want fast resolution, I want correct resolution. Because, as I said, shaving 15ms off of my DNS queries isn't helping me, at all, if it only resolves to CDNs located in China.

I don't know why you keep mentioning resolving foreign (China) instead of local content networks... My ISP is fairly localized. Its private recursive DNS servers are advertised to be optimized to provide the best routing possible to common websites (or CDNs) for it's downstream customers. And in my area, it is generally regarded to provide better performance, over all, not just resolving speed, than the Google servers (maybe due to ads) and other popular choices such as OpenDNS. This isn't just a blind DNS algorithm. The ISP continually works to make sure that the best routing paths possible are used between their customers and the most popular CDNs such as Netlix, Youtube, etc. One striking example, is that some Youtube DNS requests are routed directly to the ISP, who caches some of the most popular youtube content... No, I don't know all of the intricacies as to if/why they are better, or even if they are better to a degree that is meaningful for accessing certain content. But overall, performance does seem to be at least somewhat better when I use my ISP's private DNS servers.

I think this may, to some degree, have to do with the fact that my ISP is a re-seller from a larger, national provider, while my particular ISP is more localized, at least making local routing more efficient... But I'm not sure about how exactly this plays in.

Glorious wrote:

UnfriendlyFire wrote:

I'm not defending Mediacom. Maybe they are money-grubbing bastards. All I am saying is that your test didn't even remotely prove the null hypothesis and it is extremely unlikely that they are throttling "Youtube" because "Youtube" is a gigantic CDN. Yes, maybe they are being shady using their DNS to deliberately point you to an overwhelmed server, but you shouldn't even start pointing fingers like that until you're tried the simplest things first: Did you use Google's public DNS 8.8.8.8 ? See if that solves your issue.

Checked my router and laptop, and it appears I had set both to use Google's DNS a few years ago.

So the issue isn't with the DNS unless if other Google DNS users had similar Youtube issues.

steelcity_ballin wrote:

In short, Verizon started shaping all my content and slowing it down.

Is it still slow, even if you pipe all your traffic thru a VPN? Or if you try dynamic DNS?

Just wondering if the usual workarounds still apply, or if Verizon finally moved on to DPI and L7 shaping.

steelcity_ballin wrote:

Twitch.tv because useless. In short, Verizon started shaping all my content and slowing it down.

I have FiOS too and also watch Twitch.tv. They don't really "slow down" the content, there's something else. Try monitoring your connections while watching some streams. What I discovered was that Twitch.tv was feeding their content to me from their "sfo01.justin.tv" content distribution servers (there are many of them, they go like "video5.sfo01.justin.tv" and such) and some from "jfk01.justin.tv" servers. All the content from "jfk01.justin.tv" was playing perfectly fine (I am located in NYC and "JFK" is the code for local airport) whereas ALL of the content being fed from "sfo01.justin.tv" servers was often buffering. I solved that issue by blocking the "sfo01.justin.tv" on my router's firewall, I don't get any serious buffering anymore while watching any streams (just an initial random buffering when connecting to "non-partnered" streams but it goes smooth after first couple of minutes).

UnfriendlyFire wrote:

Checked my router and laptop, and it appears I had set both to use Google's DNS a few years ago.

So the issue isn't with the DNS unless if other Google DNS users had similar Youtube issues.

Actually it could be.

You will be using whatever is closest to the Google server that you get anycasted to, which could potentially be quite far away from your ISP. Many ISPs have a local Google cache server, by not using the ISP DNS you will not use that and your data will have to travel over potentially several congested peering points. Google could have fine bandwidth off their servers which their DNS points to, but your ISP may not care about congestion in that direction because of their cache device, or they are pointing at a different Google data centre via their DNS server.

Glorious wrote:

Beomagi wrote:

How accurate is this?
http://mashable.com/2014/06/02/john-oli ... -main-link

I have no idea, and no interest in watching some snarky comedian pretend that he understands a policy. His goal is clearly to entertain, not inform. It's sad that anyone would even cite such nonsense seriously.

Having seen the video before I can tell you that Mr. Oliver's writing staff doesn't fully understand the situation. For example the writers manage to mix up a discussion about peering and the last mile. Meaning they didn't really understand what the original and now defunct net neutrality rules did in the first place.

Mr. Oliver also approaches the situation as Netflix purely being the victim, which as this thread (and another thread from just weeks ago) has detailed isn't the actual story.

I do get the impression his writers try to be informative and funny at the same time, but like many journalists today, they just aren't willing (or don't have the time) to truly research and understand the situation.

If you really want to suss this out, look no further than Mark Russinovich's TCPView:

http://technet.microsoft.com/en-us/sysi ... 97437.aspx

Launch the proggy, then launch a problematic web site or streaming service. Take screenies at regular intervals, then try to figure out where all of the TCP/UDP connections actually come from. It resolves all TCP and UDP connections and will give you host names. Figure out exactly which Azerbaijani CDN is harshing your NetFlix viewing.

Yes, I know he "sold out", but his widgets are essential in making sure Windows of any version plays nice.

NOTE: This doesn't tell you WHY it might be happening, just that it is. A few printed screenies showing NetFlix coming from East Timor would be better ammo when you buttonhole your ISP about their CDN peering policies.

There's no need to even download extra utilities for latest Windows users - people can just open Resource Monitor and use "Network Activity" for basic diagnostic, it can also resolve addresses for content distribution servers when you're watching some video streams: