Actual usage of bandwidth

The following assumptions have been made when formulating these calculations;

No retries, packet losses or other events occur

One way, one to one host communication data and overhead

An IP MTU of 1500Bytes

A host TCP MSS of 1460Bytes

TCP & IP packet headers of 40Bytes (no TCP options)

Use of a full duplex communications medium, i.e. the full bandwidth is available both upstream and downstream, at the same time

Where division of the data into the maximum packet size results in a fraction, a packet for that remaining data must still be transmitted so we always round up when calculating the number of packets

Units of Measurement

The abbreviations used with the data/traffic values in this article are metric prefixes (aka SI prefixes) indicating decimal multiplication (rather than binary prefixes (based on powers of two) where 1kbit = 1024bits), as follows;

1 kB = 1,000 Bytes (8,000 bits)

1 MB = 1,000,000 Bytes (8,000,000 bits)

A few things to remember;

Serial line speeds are typically quoted using binary prefixes, so a 2Mb E1 is actually 2.048Mb using metric prefixes

Ethernet speeds are typically quoted using metric prefixes, so a 100Mb Ethernet link is exactly that (100,000,000bit)

Linux commands display file size information using metric prefixes. However, using a –human-readable or -h switch normally results in output using binary prefixes which is rather confusing

Windows displays file sizes using binary prefixes. To make accurate calculations, view the file properties or use a command prompt to discover the file size in Bytes and apply the metric prefix

Most other storage systems use binary prefixes

Hard drive manufacturers typically use metric prefixes which means they appear smaller than specified when capacity is displayed using binary prefixes

Bits & Bytes

1 Byte = 8 bits

File sizes are normally quoted in Bytes

Linux commands display file size information in Bytes

Link speeds are quoted in Mb (Megabits) per second, not MegaBytes, thus (ignoring all overheads) it’ll take 8s to move 100MB (MegaByte) over a 100Mb (Megabit) per second Fast Ethernet link

Other Overheads

TCP/IP handshake overheads have been ignored as these are negligible.

Ethernet transmission overheads have been ignored too (for now) but I’ll borrow some figures from Wikipedia in the summary to demonstrate how you can easily calculate that affect too.

Summary

So, as demonstrated, for data payloads in excess of the common TCP payload maximum segment size (the MSS) of 1460 Bytes, the TCP over IP bandwidth overhead is approximately 2.8%. This equates to an ‘efficiency’ of 97.33% (1460/1500) – in other words, that’s how much bandwidth is left for actual data if you’re putting as much data in each packet as possible.

However, keep in mind that for very small data payloads (common with applications such as Telnet, TN3270 mainframe emulation and SSH) the TCP over IP bandwidth overhead can be higher than 4,000%.

If you add Ethernet (and VLAN tagging) into the mix (see the calculations from Wikipedia here) then the throughput of a 100Mb link is 100 X 0.9733 (TCP/IP efficiency) x 0.9728 (Ethernet (with tagging) efficiency) which equals 94.68Mbps, which I assume means the combined efficiency is 94.68%.

Add in your security protocol (AES would drop the figure to 87.7%), session and application overheads and you start to see where all your precious bandwidth is going, if it is precious. If you’re not filling every packet to the brim you can imagine the loss can get even higher pretty quick.

With HTTP for instance, a large number of headers, large cookie values, multiple cookies and the like can literally consume a further 25% of your bandwidth without you even trying, or realising.