Trace Route, anyone know how to troubleshoot?

Unfortunately once the traffic leaves your network, you're at the mercy of your provider at to where it goes next. Route tables are often built dynamically, although I'm also surprised your route is changing mid stream. My only guess would be due to redundant connections in your providers network.

As far as Hulu stating you must get to their servers within 12 hops, that seems a little iffy to me. Inside larger corporations a user may have 5+ hops before they even reach the internet.

One thing I did notice however when doing tracerts to www.hulu.com - I was being sent to a different IP address each time, with number of hops ranging from 5 to 19. So what you could do is add an entry into your local hosts file (c:\\windows\\system32\\drivers\\etc\\hosts) for www.hulu.com and give it the IP address that gives you the least # of hops - that should enable you to hit that same server each time.

AFAIK TraceRoute will make a new connection every time you run it. It does not interfere with any other connections you may also have active to th same destination or try and trace one of them.

That's an interesting idea. Mike are you getting smooth hulu at all? If so can you determine which IP you are connecting to that gives you the smooth hulu.

it may help determine if its a hops issue or a hulu server issue.

just a guess, but how about the one that gives the least number of hops?

well its trial and error. try setting the local hosts file to a server with few hops. and see if it helps, if it does, i'd leave it at that.

if you CAN get smooth hulu sometimes try different ips and document which get smooth playback.

pm am with the ip that have smooth playback, and don't tell anyone else. I hate for you to do all this hardwork and and have everyone connect to the same server and screws things up.

Just in case the "I'm not sure how to do this" was in reference to determining which IP to use and how to add it to your host file:

From a command prompt type tracert www.hulu.com
You should get back something like this:
C:\\Users\\Brian>tracert www.hulu.com

Tracing route to a1700.g.akamai.net [76.7.66.82]
over a maximum of 30 hops:

1 10 ms 10 ms 10 ms nc-71-50-116-1.dyn.embarqhsd.net [71.50.116.1]
2 10 ms 10 ms 10 ms nc-65-41-232-213.sta.embarqhsd.net [65.41.232.2
3]
3 26 ms 10 ms 27 ms host61.sprintnetops.net [206.107.116.61]
4 10 ms 10 ms 10 ms host82.embarqservices.net [76.7.66.82]

Trace complete.
(the red highlight was added to show you what IP address I'm referring to)

So that attempt only took me 4 hops - (pretty sweet actually...)

Repeat that process a few times and see what IP address comes back with the fewest # of hops. If it keeps resolving to the same IP address each time, type "Ipconfig /flushdns" at the command prompt (without the quotes) and then try the tracert again.

Once you've determined the IP address that is giving you the least # of hops, click Start, Run and enter the following: notepad c:\\windows\\system32\\drivers\\etc\\hosts

Notepad should launch with your hosts file loaded (NOTE: the hosts file has NO file extension). Move to the bottom of the file (last line is probably 127.0.0.1 localhost) and add the IP address you determined above, press the tab key, then enter www.hulu.com

Press enter, click File, save and then exit notepad.

Then try hulu again...

I was having the same problems as mentioned, so I did what you suggested.

When I did the tracert I was getting the same 2 different ip's no matter how many times I flushed the dns, with a result of 9 jumps, but 3 of them timed out each time.

So I tried that IP you added in red with a result of 19 jumps. But at least that ip was faster because it did not have any time outs.

I am going to keep trying, but it looks like my local Cox cable provider only gives out 2 ip addresses to hulu from here.

One of the features of Akamai is they have multiple servers in different geographic locations. The server(s) physically closest to you should be the ones that respond the quickest (and with the lowest # of hops) but the number of users hitting a particular server could certainly affect that.

Here are all the IP addresses I received for hulu.com (actually for a1700.g.akamai.net - are your requests resolving to that same name?)

Coming from Raleigh, NC
76.7.66.75
76.7.66.82

Coming from Dayton, OH
8.21.194.120
8.21.194.139

Obviously still a distance from Arizona - perhaps another that is closer to you will post theirs.

NOTE: Hardcoding IPs like this may not always work, particularly if Hulu / Akamai change servers or perform maintenance from time to time.

using an external dns lookup service I was able to find a dns that only had 5 jumps. I then did the notepad edit like you said and now everything is smooth!

Thank you very much brianley!

The longest jump was to LA, so it was not that far

cool - perhaps you can share which external dns site you used to find the closest server? I'm sure it will help others.

I just did a search on google and found a site. I typed in the url for hulu and it gave me an IP, I then did a cmd prompt tracert on that IP to see if it was faster, It was so I used it.

http://www.lookupserver.com/


And after using Hulu for a couple of hours I have to say it has less hiccups and stutters than it did before, it's almost perfect.

Thanks again for your help!

Your hops have nothing to do with DNS and have nothing to do with host files. It has everything to do with your ISP routing tables... You can change the routing tables within your machine but honestly is very very complex which will override your routers / ISPs routers - again I dont recommend this.

I would recommend if you have QoS on your router that you configure QoS. QoS will not only prioritize the packets but also may optimize your routes . As each packet with the extra payload of its purpose and prioritiy go through each hop the router will establish a contract of guaranteed service. Typically hops don't necessarily dictate latency or jitter. Usually what affects traffic is quality of the link and inbetween. Ideally the lower number of hops the better quality but sometimes depending on the type of traffic and the priority of those packets will dictate the latency (delay of packet arrival) and jitter (variation in the delay of the packet arrival). Jitter is typically your biggest issue when it comes to media streaming and gaming - which is why there are routers out there with "anti jitter" or "jitter reducers" like the Dlink Gamer routers. They employ at the end of the day QoS (hidden by some fancy name like GameFuel Mode or something like that). This helps significantly.

Dont waste your time with your host file that is just like hard coding an IP to a DNS name.. Once your DNS has been established your using DNS cache... And as the previous poster stated Akamai is uses complex algorithms to drive you to the least used route to their services - much better then you could hard code (which is why I dont recommend you muck up your routing tables).

QoS is your best bet... if you have a Dlink router then enable GameFuel.. the newer models actually can easily prioritize based on media type (Games, Video, VOIP, etc.)

The DNS TTL on the hulu.com DNS entries is 20sec, so your machine only caches the entries for 20sec, if a subsequent connection to hulu.com is made after 20sec, you may get a different ip, and therefore a different route. Routes to a specific ip generally don't change that often, so hardcoding a hosts entry to an ip with least amount of hops may help. Of course if hulu.com every changes ip's you won't be able to connect and will have to go through the exercise again.

Does QoS work beyond your router? I highly doubt it, your ISP would have to configure their infrastructure to accept QoS from all their customers, something I'm pretty sure none do.

I see dont know much about network architecture..

There is Packet TTL and DNS TTL both have nothing to do with the local cache of your machine.

Packet TTL has to do with how long the packet traverses the internet before it finds its destination. It focus is to ensure that the packet in the event it doesnt cant find its destination it doesnt traverse for infinity.

DNS TTL is how long after the authoritative name server makes a change that the change propegates to other DNS servers. authoritiative name service providers typically have low TTL as they want their DNS entries to propagate very timely BUT the downfall is that this also increase load to that server. Most smaller companies for example mine has a much high TTL. Since we own and host our own DNS names/servers we dont care how long it takes (well we do but not like network solutions for example).

And again.. DNS HAS NOTHING TO DO WITH ROUTES!!!!!!!!!!!!!!!!!!!

And yes QoS is dependent on the routers passing on the payload information about the packet but any router installed after 1999 has this and will pass along that packet information... Some will block but MOST do not as it benefits the ISPs under MOST conditions.

Please give accurate information rather then fud or dont answer at all..

I was obviously referring to DNS TTL and it does affect the DNS client on Windows machines as they cache records as per the TTL of the DNS record. http://support.microsoft.com/kb/318803 (specifically the paragraph above "Using the Registry to Control the Caching Time".

You're absolutely right about propagation to non-authoritative DNS servers, but many OS's have a resolver cache as well. Don't believe me? Ping a hostname, and run ipconfig /displaydns , the TTL is obeyed and shown as per the RFC.


True, but indirectly routes are affected since whatever ip gets resolved will likely have a different route.


Go read the RFC for DNS http://www.ietf.org/rfc/rfc1035.txt

This is getting off topic, I'll stop responding to this "fud".

Just FYI - Working for 2 huge providers and over 10+ years of WAN experience - I don't care what you set your QoS to, your ISP doesn't care...Unless you are paying for your ISP to do QoS...Your internet data on a residential plan is thrown into the lowest bucket for class of service. Shoot, for that matter most of the backbone connections dont even use QoS, when you are talking OC-192s etc. Setting QoS on your local Linksys router, only prioritize traffic on your network going out. For instance I have 25mb pipe out of my house, using DD-WRT on a Linksys WRT-54G, I have VoIP priority over anything on my pipe so that I have always have the ability to carry on a phone call regardless if I'm gaming or doing large ftp transfers. But does the provider care? Nope...

Anyway.. I agree its way off topic and I see there is a ton of FUD created and misinformation..

Fundamentally we are in violent agreement... but I have personally seen benefits configuring QoS ... For fact FIOS uses QoS as part of their network, so does Cablevision. Any cable provider that provides voice or video streaming passes through QoS. Not all providers will BUT most cable internet providers do...

probably.

Because you keep listening to the others... Im a broken record but DNS has very little to do with the routes that are taking for a specific IP. Just because you have high latency doesnt necessarily mean you will have diminished video performance. What affects Video (which I stated earlier) is jitter. Its better to have a consistent latency the a fluctuating relatively low latency - at least for VOIP or Video. Most likely Hulu Desktop some type of packet optimization which is typically a benefit of a fat client over a light weight client (ie browser based) - developers can introduce more trickery to ensure a more consistent flow of packets.

Either case you are wasting your time-- just watch using the desktop, get a device the employs QoS properly (no guarantee as previous discussion) or have your ISP change the routes to the hulu servers.

Glad you mentioned FiOS, I work for Verizon on one of the FiOS teams...your voice, internet and TV all go out on to separate networks within Verizon. Verizon could care less what you have setup for QoS on your local network, we don't honor it. What you are seeing is QoS on YOUR network, and yes your linksys router or whatever will prioritize traffic on your network going out, but once it hits Verizon, we don't use your linksys' QoS stuff

You only put in a host entry for www.hulu.com? Does the stream come from www.hulu.com, probably not. Best would be a wildcard on a local DNS server for *.hulu.com, but even then the actual video feed may be coming from a different domain. The only sure fire way to find out where the stream is coming from is running a network dump and reading it with a protocol analyzer like wireshark.org. Quick and dirty, is install wireshark with included winpcap, run a capture and make sure it's on the right network interface, run a hulu stream and try and find the video stream, and find the DNS request before it that matches the ip the stream is coming from. The video stream should be fairly easy to find, it should be a large amount of UDP packets(I assume as it's a video stream). I can't say for sure as I'm in Canada and we don't have hulu access and I can't try it myself.