What mlb.tv Revealed to Me About My Router Configuration

I recently re-subscribed to Major League Baseball's video streaming service mlb.tv.  I used it last August and September to follow pennant races and had generally good results using my MacBook connected via wi-fi both at home and while traveling.

This year, however, my experience was immediately horrible.  I could not get past the bandwidth/quality check that happens after the media player browser window is launched.  I verified that I had the latest versions of the Flash Player and NextDef plug-in.  I rebooted.  I tried Safari, Firefox and Chrome.  I enabled all cookies and pop-up windows. The results remained the same.  When I checked network traffic in Activity Monitor, I saw throughput peak at about 35 kBps.

To determine whether the behavior was specific to the MacBook, I tried to connect from my desktop PC.  Nothing new.  I then downloaded the mlb.tv application to my PS3.  I got some sound and a very halting video stream.  That told me very little, but at least was consistent with the small amount of network traffic I had observed.

Very late last night I resumed the investigation from my PC.  I was able to get sound and some video.  Network throughput was higher, 50-150 kBps.  I used the sysinternals Process Monitor to determine the server to which Chrome was connecting, which turned out to be hosted by Akamai rather than MLB itself.  I was surprised, however, to discover that tracert showed the server connected to Level3's network in Los Angeles.  Akamai's service should connect me to a nearby server; I am in Philadelphia and served by Comcast.

Believing that Akamai uses DNS locality to pick a server, I checked the DNS addresses in my router.  Running tracert for these showed that they were both on the Level3 network in Los Angeles.  My past experience has been that DNS servers should be local ones specified by Comcast when the router does its DHCP initialization.

Looking through the configuration for my D-Link DIR-825 router, I discovered that an option labelled Enable Advanced DNS Service was checked.  I unchecked it and rebooted the router.  The router came up with DNS addresses that I recognized as Comcast (68.x.x.x).  In fact, they matched the Philadelphia addresses listed at http://dns.comcast.net/dns-ip-addresses.php.  I immediately fired up mlb.tv, got an excellent video stream, and saw my network traffic vary from 0 to 1.1 MBps.  All is well on my PS3 and MacBook, too.

I don't recall checking the Enable Advanced DNS Service option.  It may have been added or checked during a firmware upgrade.  Had I known that it would override the DNS server information provided by Comcast and instead use a DNS server across the country, I certainly never would have selected it.

Getting Good Results With Vonage

Frequent service outages combined with long resolution times from my land line provider (Verizon) finally convinced me to try Vonage. The current Vonage deal ($15/mo for the first 6 months) didn't hurt, either. I had some problems getting started, but after a few tweaks, my service is running smoothly.

My home (Ethernet) network uses a D-Link DIR-825 router with a Motorola SB5100 to connect to the Internet via Comcast. Besides some switches used to distribute Ethernet throughout the house and within my home office, I have a VOIP device connected to the router that I use for work. My experience with that device has been great (plugged it in, flashed it, and it worked), but I was worried that I would not be able to get two VOIP devices to play nicely on my network.

I signed up for Vonage through their web site, moving my land line phone number to the Vonage connection. It was 7 days before the number was moved.

Vonage provides a device they call V-Portal for free as part of establishing service with them. The installation instructions place this between the cable modem and existing router. I reluctantly proceeded this way and quickly discovered that the V-Portal includes an embedded router and firewall.

Within 15 minutes I had come upon a deal breaker. I use PPTP VPNs to connect to various networks for work. Going through my D-Link and the V-Portal, I was able to establish VPNs, but within 2-3 minutes the VPN was dropped.  This is presumably a double-NAT issue, since data was traversing two routers.

My response was to reconfigure my setup to have my D-Link router connected to the cable modem with the V-Portal plugged into an Ethernet port off of that. My VPNs stopped dropping and the V-Portal still worked with my phone. The only negative of this configuration is that I had to connect a computer to the LAN port on the V-Portal to access the web management interface and enable management through the WAN, since the WAN interface on the V-Portal is the one that is accessible from my home network.

With the networking side appearing to work, I prepped the home phone network for Vonage. This simply meant disconnecting the network from the provider interface. In other words, I removed the cable coming from outside the house from the interior connection junction for my phones. This put all the phones in the house back in business.

One remaining problem slowly became apparent. During a call, audio on our side of the call would go dead for one to several seconds. The people to whom we were talking claimed no similar problem.

The most likely culprit seemed to be dropped outgoing packets. My initial cynical conclusion was that Comcast somehow determined these were Vonage VOIP packets and intentionally dropped them.

Looking for a solution within my reach, my attention turned to the D-Link router. It is a well regarded product with many features, any of which could be causing a problem. Browsing the options within the Advanced tab of the configuration application yielded many possible culprits and an equal number of promising options for a solution.

My first forays were changes to the WAN Shaping configuration, all with no efficacy. My attention then turned to the QOS engine. When I looked at Internet sessions, I could see that connections for both my work VOIP and Vonage devices had higher numerical priority values than other connections. Reading the on-line help indicated that lower numerical priority values were actually given higher priority. That sounded wrong (VOIP should have higher priority). I considered setting up a rule to force a lower numerical priority for Vonage, but instead simply disabled the QOS engine. Based on our experience since, that seemed to be the ticket: no more audio dropping during calls. Having QOS turned off has not adversely affected on-line Call Of Duty play in any noticeable way, either.