All data is not created equal, so there is no need to treat all data the same. Distinguishing the movement of quality data from quantity data is a great way to prioritize network issues.
In data networks, that movement includes throughput and “goodput.” Most of us know what throughput is — the amount of data we’re able to put through a network over a period of time. Goodput is related to throughput, but has a more particular definition.
Goodput is the rate at which useful data traverses a link. Throughput includes every byte going through a link, but not all of that data is necessarily useful. Throughput minus goodput equals a sort of digital noise that reduces the effectiveness of a network. That digital noise includes:
Protocol overhead: Network communication protocols such as TCP/IP wrap their payloads in layers of headers that help insure delivery. These headers are necessary, but not considered part of goodput.
Data retransmission: When required packets do not arrive at their destination, they are retransmitted by the sender. Retransmissions indicate a failure in the network path, often due to an overloaded or failing link.
Applications use the network to deliver data to their users. For example, a web browser makes a connection to an HTTP server. The HTTP server talks to a database. The database server checks credentials against a domain controller. All of those transactions traverse a network. Application designers want those transactions to be completed as quickly as possible, necessitating a high goodput rate.
When goodput and throughput rates are nearly equal, goodput is maximized. Network management stations (NMSs) and tools such as Cacti measure link throughput using SNMP. Switches display interface throughput via a simple command. Measuring goodput, however, is not that easy.
Tools that measure goodput are available, but they are overkill. Instead, IT staff should look for underperforming links with the following problems, which can lower goodput:
Frequent high utilization: A link with 80 percent-plus utilization probably experiences 100 percent utilization in bursts. NMSs sample interface statistics at intervals, averaging utilization between polls. Traffic bursts that overload a link are masked by the intervals.
Discarded packets: An interface that receives a packet, but is unable to forward it, experiences an “out discard,” implying a packet drop.
Link errors: Occasional sporadic errors are normal, especially on WAN links. But when error counts climb steadily, the issue should be addressed.
These link problems indicate that packets were likely dropped, increasing retransmissions. Retransmissions decrease goodput, reducing overall application performance. Pinpoint these issues in your network by monitoring as many interfaces as possible.
Fixing a goodput problem can be done in a couple of ways, both of which need to be communicated to management.
1. A network redesign might alleviate a bottleneck. For example, equal-cost multipath routing can be helpful and often costs nothing. Traffic shaping on capable WAN routers can also improve goodput at no extra cost.
2. A network upgrade might be required. Even in a small business, going from 1 gigabit per second to 10Gbps, or 10Gbps to 40Gbps, is appropriate at times. Congested WAN links might need to grow, but moving to higher speeds can be expensive.
The result of these efforts should be improved application transaction time — and if your customers can get their work done faster, your goodput improvement project has been a success. But keep in mind there are many reasons an application might be slow. Perform due diligence on the application to be sure the cause of poor performance has been properly identified.