Help & troubleshooting for network issues, including connecting your device to your home Wi-Fi network, connecting to public networks, troubleshooting wireless issues & ethernet connections, and optimizing streaming performance.
"davedave" wrote:
TWC sends me to a CDN in Chicago
OpenDNS sends me to a CDN in San Jose
SpeakEasy sends me to a CDN here in Los Angeles
Technically the servers you were routed to are all part of one CDN operated by Limelight Networks:
"davedave" wrote:
My favorite solution would be for Roku to update their software so it is not dependent on DNS for locating the nearest/best CDN.
I'm curious how you envision your player finding the closest Limelight content delivery server without relying on DNS. (I assure you I am not being sarcastic or trying to be jerk. I am honestly curious to hear if you have a better solution.
)This is not really a Roku problem but rather a Limelight problem. Notice that the seventh hop in all of your routes is a Limelight edge server. Everything past that point is on the Limelight network. Since Limelight knows the resource you are requesting, your IP address, and the BGP route from the edge server back to your ISP's network there is no reason for them to route your request all the way across the country if the requested resource is available at a closer location. Such static routing on their own network would imply that Limelight does not perform even basic load balancing.
The whole reason for paying a premium to put content on a CDN is because the CDN is supposed to transparently route the user's request for content to the appropriate caching server based on the user's location. The user (or the user's device) should not have to query each URL on multiple geographically distributed DNS servers then perform speed tests or traceroutes to each resulting IP address in order to find the best location. That is the sign of a very crappy CDN that is fundamentally not doing its job.
In short, I don't understand why Roku should be responsible for covering Limelight's inability to manage their own network.
"eri3k" wrote:"davedave" wrote:
TWC sends me to a CDN in Chicago
OpenDNS sends me to a CDN in San Jose
SpeakEasy sends me to a CDN here in Los Angeles
Technically the servers you were routed to are all part of one CDN operated by Limelight Networks:"davedave" wrote:
My favorite solution would be for Roku to update their software so it is not dependent on DNS for locating the nearest/best CDN.
I'm curious how you envision your player finding the closest Limelight content delivery server without relying on DNS. (I assure you I am not being sarcastic or trying to be jerk. I am honestly curious to hear if you have a better solution.
Let's start with my guess on how it works now...
1) Via DHCP, my Roku box is handed the IP address of a DNS server, which has [usually] been provided by my ISP.
2) The Roku box contacts this DNS server to determine the IP address of cdn.netflix.com
3) The DNS server responds with whatever is currently in its cache.
4) The Roku box contacts the supplied IP address and requests a stream.
The problem is that in (3), my DNS server (be it TWC, OpenDNS, SpeakEasy, etc) may have cached an IP address that is not geographically close to my Roku box, but instead geographically close the DNS server I'm using. The limelight DNS servers tell the ISP's DNS servers the IP address of the limelight CDN network closest to the ISP's DNS server. Not sure what else it could do as the limelight DNS servers have no knowledge about the location of the devices that will be querying the ISP DNS servers.
For TWC: It appears that the TWC DNS server is in Denver, so that may explain the selection of Chicago over the closer Los Angeles and San Jose.
OpenDNS: My guess is that OpenDNS attempts to be smart and requests limelight DNS servers from various points around the country and then caches all these responses. When a request comes in from my Roku box to the OpenDNS server, OpenDNS attempts to guess which of the limelight CDN IP addresses is closest to me (based on knowledge of my IP address) and give me that. Either OpenDNS doesn't have any DNS servers closer to me than to San Jose (and hence the limelight DNS servers will never send OpenDNS the IP for the limelight servers in Los Angeles) or OpenDNS has guessed my location incorrectly.
SpeakEasy: The SpeakEasy DNS server I tested against is based in Los Angeles. So when it requested the CDN IP address from the limelight DNS servers, limelight told it the IP address of the LA based CDN. Which is why it worked nicely.
Assuming the above is [mostly] correct, Roku/Netflix/Amazon/Limelight have three choices
(A) ask every internet user to reconfigure their routers so it uses a DNS server that is geographically close to them
(B) contact every ISP and somehow convince them to place DNS servers geographically close to all their users and/or increase the smarts of their DNS servers to answer with CDN IP addresses that are closer to their customer.
or
(C) stop relying on DNS to determine the closest CDN server.
The answer so far in the forums has been to do (A) or (B).
To do (C), Roku/Netflix/Amazon/Limelight could...
(C1) set up a server that can be contacted by the roku box, say via NearestCDNLocator.roku.com (or whatever). The IP address(es) of this server resolved via standard DNS tech. This server would take the client IP address of the roku box (or its router/cable/dsl modem) and determine the CDN that is closest to that IP address and tell the roku box to acquire content from that IP address. Thereby bypassing all the problems with DNS caching from non-local ISP DNS servers. Basically, Roku/etc would be building THEIR OWN cache-less DNS system for the CDN servers -- bypassing any issues with users routers/ISPs.
(C2) the roku box somehow retrieves a list of ALL CDN IP addresses and checks ping times and/or hop counts to ALL the limelight servers and picks the best one.
(C3) the roku box allows the user to select their preferred CDN location from a dropdown list. If it is unavailable, it defaults to some other selection method.
Maybe I'm completely misunderstanding how all this works.
You are pretty much right about how the current process works. OpenDNS uses split-horizon DNS which enables it to resolve different IP addresses at each of its caching locations even though every user enters the same two DNS server addresses. (See it in action by checking cdn.netflix.com here. Can you find the problem with some of these Limelight entries?)
Your C1 has the same problems as the current DNS-driven system, namely that an IP address alone does not give you a location. That is especially true when you are talking about large multi-region ISPs shuffling blocks of dynamically assigned IP addresses among geographically distant users. The other two proposals would probably work, but they still require Roku to do what is essentially Limelight's job. And it looks like Limelight could very easily break the system in the process performing routine network maintenance and leave Roku holding the bag.
My proposal is for Limelight to use its edge servers to look at incoming requests and determine whether the content can be served from that location:
With this system there is no need to ensure that every DNS server resolves the IP address of the closest CDS or examine the requester's IP address to find out where the player is located; the point where the request enters the Limelight network provides all the necessary location information. Users would be bounced to farther location only if the nearest location: 1) does not have the content they requested, or 2) is overloaded.
This is what Limelight should already be doing. The fact that they are not should make their customers (Netflix and Amazon) royally pissed. The end user should not have to deal with any of this crap. The fact that we do is a very, very bad sign.
Your C1 has the same problems as the current DNS-driven system, namely that an IP address alone does not give you a location. That is especially true when you are talking about large multi-region ISPs shuffling blocks of dynamically assigned IP addresses among geographically distant users. The other two proposals would probably work, but they still require Roku to do what is essentially Limelight's job. And it looks like Limelight could very easily break the system in the process performing routine network maintenance and leave Roku holding the bag.
My proposal is for Limelight to use its edge servers to look at incoming requests and determine whether the content can be served from that location:
With this system there is no need to ensure that every DNS server resolves the IP address of the closest CDS or examine the requester's IP address to find out where the player is located; the point where the request enters the Limelight network provides all the necessary location information. Users would be bounced to farther location only if the nearest location: 1) does not have the content they requested, or 2) is overloaded.
This is what Limelight should already be doing. The fact that they are not should make their customers (Netflix and Amazon) royally pissed. The end user should not have to deal with any of this crap. The fact that we do is a very, very bad sign.
