The satellite industry has a problem. As we have shifted from analog to digital to IP-based transport, manufacturers of satellite hardware are now being compared to manufacturers of terrestrial and wireless networking gear. Unfortunately, the satellite industry has some catching up to do.

After being repeatedly pummeled by corporate, government and military end user for inflating the performance statistics of their routers and switches, manufactures of terrestrial networking hardware started adopting the testing tools their customers were using to evaluate the manufacturer’s gear. It didn’t take long before OEM manufacturers of networking hardware became the largest purchasers of these testing tools. The manufacturers took the admirable step of drawing a line in the sand, saying “We will provide accurate and meaningful specifications in our marketing material.”

The satellite industry hasn’t taken this step yet.

This article discusses the lack of relevant packet per second information for satellite modems; why the packer per second rating is more important than the speed of the modem in certain applications; and reviews practical steps that every satellite service provider and teleport operator can take to evaluate the packet per second performance of different satellite modems.

Understanding Packets Per Second in Satellite Modem Performance

How many times have you encountered a remote satellite terminal with seemingly inexplicable and intermittent problems? Your network diagnostic reports indicate that the site works perfectly some of the time, even when the service is running at 100 percent bandwidth utilization. Yet at other times the quality of Voice over Internet Protocol (VOIP) calls is virtually unintelligible or calls may drop completely. Unfortunately, there seem to be far too many of these “horror stories” from end users. It is bad experiences like these that can taint the reputation of satellite communications in general.

The good news is that it is entirely possible to minimize the likelihood of this problem and ensure that clients consistently experience excellent service quality. The starting point for such a solution is to understand the nature of the traffic and to appropriately characterize the equipment being used for the end-to-end service delivery. In practical terms, this usually means focusing on the satellite modem as the most likely “bottleneck” to service delivery and actual user throughput.

There is More to Modem Performance Than Speed

Many people assess a modem’s capabilities purely in terms of speed. If a modem can achieve 8 megabits per second (Mbps) of throughput, then surely it can carry say 20 simultaneous VOIP calls? At a typical 24 kilobits per second (Kbps) per call, 20 concurrent calls should consume only 480 Kbps in each direction. So the modem should easily be able to handle it, right? However, in actuality such a traffic load could significantly exceed the capabilities of some modems – even those that can “easily” handle 8 Mbps!

The key parameter to understand is the packet per second (PPS) rating of the given modem. Every incoming Internet Protocol (IP) packet needs to be processed and then queued for transmission. The more processing the modem needs to perform, the more the central processing unit (CPU) and memory resources are consumed by the flow of packets.

Recall that a full-sized IP packet is 1,500 bytes in size. 8 Mbps of throughput is a mere 680 packets per second (of full sized packets), and easily handled by pretty much every satellite modem on the market today, regardless of manufacturer or bandwidth access scheme. By contrast, applications such as VOIP generate a steady stream of small packets. For example, G.729, the protocol used in many VOIP systems, generates real time protocol (RTP) packets once every 20ms, with each packet consisting of approximately 20 bytes of voice payload, plus 12 bytes of RTP header, 8 bytes of user datagram protocol (UDP) header and 20 bytes of IP header. This creates a grand total of 50 packets per second in each direction, each packet being 60 bytes in size, for a typical VOIP packet.

1 VOIP Packet = 20 bytes voice + 12 bytes RTP + 8 bytes IP header

Supporting 20 concurrent VOIP calls therefore generates 1,000 packets per second, yet only 480 Kbps of traffic (plus any extra framing overhead), in each direction. Unfortunately, the total load of 2,000 packets per second is more than the CPU capability of many modems deployed at remote sites today. This is one common reason why end users intermittently experience poor voice quality or even cases of modems locking up or rebooting. The modem might have been quite capable of handling 2 or 3Mbps of traffic, including a mixture of Transmission Control Protocol (TCP) traffic and perhaps 4 or 5 VOIP calls. But if ten, fifteen or twenty concurrent VOIP calls are placed, it can cause the CPU to “max out”, and lead to the degradation or loss of communications for all services, voice and data, through the affected modem.

Understanding the Traffic Profile is Key
All is not lost. There are live VSAT terminals today supporting in excess of 100 concurrent calls through modems of both the TDMA and SCPC variety. The key is to make sure that the traffic profile is well understood in terms of protocols, packets per second and throughput (in KBPS). Ensuring that the selected modem can easily carry this load, with some room to spare, will enable the performance and reliability that the end-user expects.

While rated throughput figures, in Mbps, are prominently displayed on most VSAT modem brochures, the packet per second figures can be remarkably elusive! This is partly explained by the variable nature of the PPS characteristic. A “safe” PPS figure varies, depending on the exact mix of protocols being passed at any point in time (TCP vs. UDP vs. IP etc.). It also varies based on the mix of packet sizes of each stream, and on performance improvement features that may have been enabled, such as TCP acceleration or Compressed Real-Time Protocol (CRTP).

For the satellite modem manufacturer, to express a conservative number invites potentially unfair comparisons against a competitor’s more optimistic number. Since most potential clients seem unaware of the importance of the packet per second parameter, it is often tempting for manufacturers to simply leave the PPS rating undisclosed. Like most technologies, the only way to really know how a satellite modem will perform under different traffic profiles is to test it, and test it thoroughly.

Real World Modem Tests Highlight the Packet Per Second Impact
There are a myriad of ways to load test modems and complete sub-systems, but two very convenient methods are the ubiquitous Iperf and the Java GUI Jperf IP performance tools. Operating in a traditional client-server model, one modem is connected to a server to receive traffic, while another modem is connected to a server that generates a source of traffic, and simulates different applications.

In the following example, a stream of 34 Mbps of UDP payload has been generated by the client. It is transmitted over a system consisting of the originating client (on a Linux server), a Cisco ASA firewall, two Ethernet switches, a fiber optic link, two more Ethernet switches, a satellite modem (of undisclosed make and model), and then a matching satellite modem at the remote site, feeding via one more Ethernet switch into the terminating Jperf server.

Figure 1 shows the command issued on the client end, causing 521,741 datagrams of 1,470 bytes of UDP payload (hence 1,498 bytes per IP packet) to be generated within the 180 second test period:

During this initial test (Test A), the remote site server end received the 34 Mbps stream of UDP with a total of 0.049 percent packet loss (254 packets of the 521,741 didn’t arrive), and with less than 1 ms jitter.

The Iperf bandwidth measurements are with regard to the payload component of the datagrams that are created, not the overall IP traffic. For this specific case, the 34 Mbps of payload translates to 34.7 Mbps of IP traffic. As previously discussed, full sized packets are relatively easy for a modem to carry. It’s important to test throughput with a suitably large number of small packets.

Table 1

2 Mbps stream of UDP payload resulting in 3,125,002 packets being generated in 300 seconds, which is a stream of just over 10,400 packets per second. For the VOIP simulation, the 24 byte payload, results in a total IP packet of 52 bytes, hence the over-the-air IP traffic of this 2 Mbps payload stream was 4.5 Mbps (including VLAN tagging). While the packet size was considerably smaller in Test B, the number of packets generated per second was 3.6 times greater than in Test A. Packet loss in Test B was comparable to Test A, at significantly less than 1 percent. Table 1 above compares the results of the two tests.

The 10,000 packets per second performance illustrated in Test B is sufficient to carry 100 concurrent VOIP calls or significantly more, when used in combination with other end-end system engineering techniques. As a result, the satellite modem in this particular test is capable of supporting the packet per second rate necessary to sustain a large number of concurrent voice calls, as well as a multimegabit per second data rate with much larger packet sizes. Performing this type of testing across a variety of platforms can be a valuable tool in selecting the right type of satellite modem platform for a particular network traffic profile.

Selecting the Right Modem is Just the First Step to a Complete Solution
Modern satellite modems and systems are capable of carrying very significant traffic, measured both in terms of raw throughput, and also in packets per second. The careful selection of the appropriate technology to safely fulfill a given client mission, is paramount to achieving ongoing client satisfaction and success.

End-users seeking a high-quality satellite communications service need to either conduct their own modem testing or select a satellite network service provider that is fully cognizant of the issues. While selecting the appropriate equipment is a critical element of designing a network, it is just one of many steps necessary to fully engineer a satellite communications solution that will meet or exceed the desired end-user performance expectations.

Chris Hill is the Chief Technology Officer for ITC Global, a satellite communications solutions provider to the Energy, Mining, and Maritime Markets. Chris is responsible for ITC Global’s strategic capabilities and global network infrastructure and oversees the identification, testing and integration of new technologies for customer solutions. He is a senior member of the IEEE and an alumnus of RMIT University.