Dish network for the enterprise

Despite the widespread availability of wired broadband, there are still scenarios where an enterprise might consider satellite connectivity. And that led us to conduct a groundbreaking test of the HughesNet VSAT service.

After all, there are locations where Internet connections are simply unavailable, are supported by POTS modem lines, or have single (and perhaps not very reliable) data circuits.

Furthermore, satellite links can serve as an effective backup in the event of natural disasters (and backhoes) that make primary Internet circuits disappear.

The satellite dish as a digital circuit seems like a long way to send packets (44,000 miles roundtrip), but we connected Hughes Net to our lab in two scenarios -- as a fault tolerance availability link and as a sole Internet circuit emulating a branch office/site connection -- and found the speed and service to be acceptable if you tune it properly. And tuning applications for the latencies interjected by satellite links is what Hughes technicians do.

The tuning specifically involves applications, as some applications are abnormally latency sensitive, or in the case of Microsoft's Active Directory authentication process — very chatty. The chattiness of various protocols, a ping-pong effect, is exacerbated by the latency of the circuit path, which is typically around 600 milliseconds. Compared to most WAN links, 600ms is a lifetime.

Dealing with latency and common application or service process response under such latencies is the sort of problem that HughesNet engineers like to dig their teeth into.

How it all played out

At first, we asked to take a broad look at how VSAT works, using varying applications. It turns out Hughes just doesn't work with customers that way and for a rational reason, we found. They're more reality-based, rather than theoretical.

There are two offerings Hughes makes; one is an ala carte offering where you get a dish, and account, and have a jolly good time (with access to best practices and guides). The other way is vastly more sophisticated, and for enterprise clients, that's the process we eventually undertook.

HughesNet works with clients to map out the usage of the Ku-band VSAT satellite uplink/downlinks, combined with other components, especially applications and authentication components of a client's network. When we started talking to HughesNet in this way — network diagrams with specific applications (and revisions) and locales — suddenly the lights went on and things started to hum.

The Hughes business process beyond dish installation, which is often done by contractors, is to design the network, examine and potentially patch or optimize applications and services, then pilot a prototype link, which then becomes fine-tuned to alleviate real problems (generally latency-based) or potential ones, like the kind that are found in growth.

When we submitted two scenarios to HughesNet, their business processes started to digest them immediately for suggestions and modifications.

The first scenario was a link whose sole Internet circuit would be via local Ethernet, coupled then to a HughesNet datalink to our cabinet in nFrame's ISP network operations center (NOC) in Indianapolis. This scenario emulated a remote branch office network of a small size: eight users. The branch office circuit would link the workgroup's resources, including Microsoft's SharePoint, to SharePoint host via the satellite link to our emulated data center inside a well-connected NOC. Users in this scenario would be Windows-based, and would authenticate locally.

The second scenario would emulate a VSAT link as a failover circuit, replacing a "faulty" primary T-1-style link. Triggers would sense an outage in the primary link, then failover to the satellite link, hopefully with as little interruption as possible. Users would failover in a predetermined amount of time, as specified by client-side router settings.


We mapped out the scenario networks for both diagrams, from an applications but also networking layer perspective. This process went through several iterations until we agreed. We logged more calls with HughesNet personnel than any other product review we've done in recent memory.

Hughes Networks supplied us a dish that was installed by a local HughesNet contractor onto the roof of our test facility. In turn, nFrame took care of the "plumbing" which consists of taking thick coaxial cable (MIL grade RG6/U) to be linked with a Hughes Network 7700 Router/Modem to our cabinet.

The contractor was responsible for achieving the satellite dish alignment and anchoring and the initial circuit link success. He took pictures of each component along the way. These pictures also make it into the HughesNet CRM system, a customer portal (called Hughes Customer Gateway) based on PeopleSoft, backended by Oracle 10g and EMC's SMARTS network management infrastructure. The pictures are used for identification and tech support liaison work.

We linked the Hughes router appliance in our cabinet to check each test component. HughesNet pre-sales and network engineering staff used our list of proposed application scenarios to adjust the modem appliance to use varying protocols to speed our connections. Then we started testing.

General observations

The HughesNet VSAT connection adds a datalink circuit that's about 44,000 miles long, up and down. Interestingly, we found that this manifests itself largely as perceived application hesitations. Through the use of various protocol adaptations (mostly TCP spoofing), streams of data tend to follow just a small lag time, in our case, about 0.6 seconds. It's possible to watch videos at low raster size and limited color and frame rate — but you'll need to sacrifice an otherwise saturated connection. The max data rate was 249KBps, download, and approximately 59KBps upload.

In our tracking of the branch office scenario, we tracked wget (http download) times, and found the link gave us about 160KBps. When we tested http up/downloads, we noted that the Hughes modem compressed the data streams and tried to combine multiple machine http gets/puts until the bandwidth was saturated.

This compression effect was lost, however, when we used encrypted copies. Our speeds slowed when we used scp ('secure copy') to move data back and forth across the link. For our side, we had zero transmission errors, although we did have periodic slowdowns initially — that vanished before HughesNet service personnel responded (rapidly) to our requests for assistance regarding them. Maybe there was a vulture on the dish.

Primary link scenario

In our primary link scenario, we used VM-based Windows clients to connect to Microsoft SharePoint, which was in turn connected via the HughesNet datalink to another SharePoint server in our NOC cabinet (local authentication cuts chatter time, we were told and this proved true). We tested speed quantitatively through file uploads and downloads and qualitatively through Web browsing and use of Microsoft Outlook and Exchange via SharePoint.

The data performance was faster than our experience with POTS or ISDN modems, and approximately the speed of an asymmetrical DSL connection. Non-encrypted data was compressed, as noted, while binary data moved more slowly.Qualitatively, e-mail arrived and left. We shrugged. As link speeds are somewhat slow, this isn't the sort of link to download albums of MP3s or watch lots of YouTube. However, except for slight hesitations, Web browsing and get/post Web pages were judged acceptable. Connections to common sites such as FedEx and UPS seemed fine. Business can be done.

Backup link scenario

In this scenario, we wanted to failover to HughesNet when our emulation of a single-source circuit provider failed. We wanted to understand settings and implications associated with application use between a low and high latency connection and the failover settings and qualifications germane to each network configuration.

We configured our network to failover to the HughesNet circuit on command (see How We Tested). As our primary link is 100Mbps, comparing it to the HughesNet link is like putting both feet on the brake pedal, and is not transparent. We feel, however, that if an organization's primary link is a T-1 or a similar speed (1M-2Mbps-like), the cutover to a HughesNet VSAT link would show a hesitation, then show only the higher latency of the link.

We used the VRRP protocol to failover the primary link to the HughesNet link, which can be programmed on most routers for its hesitation value when a primary link appears to fail. HughesNet can use various protocols ranging from VLANs to protocol spoofing and others to attempt to maintain user and application control where that's possible.

For some applications, any failover link to an alternate provider may cause application errors; some applications can recover from them while others might have to re-establish sessions or might fail badly. This is why HughesNet personnel have become so focused on specific application infrastructure in pre-sales work.

Other satellite optimizations

For Microsoft Outlook and Exchange, we set the client to download headers only, so as to minimize downloading a full message payload. For Outlook Web access, choosing the Web access light version loads much quicker and uses far less bandwidth, we found. The savings were limited to only mail, calendar and contacts whereas the full version also allows access for tasks, documents and public folders. Using the default SharePoint services Web site was a bit slow over the satellite link and modifying it would be necessary to be less bandwidth intensive.

Henderson and Allen are researchers for ExtremeLabs. They can be reached at

Read more about LANs and WANs at Network World.

This story, "Dish network for the enterprise" was originally published by Network World.

Copyright © 2010 IDG Communications, Inc.

Shop Tech Products at Amazon