Packet Loss - Acceptable Packet Loss

Acceptable Packet Loss

“The fraction of lost packets increases as the traffic intensity increases. Therefore, performance at a node is often measured not only in terms of delay, but also in terms of the probability of packet loss…a lost packet may be retransmitted on an end-to-end basis in order to ensure that all data are eventually transferred from source to destination.” The amount of packet loss that is acceptable depends on the type of data being sent. For example, for Voice over IP traffic, “issing one or two packets every now and then will not affect the quality of the conversation. Losses between 5% and 10% of the total packet stream will affect the quality significantly.” On the other hand, when transmitting a text document or web page, a single dropped packet could result in losing part of the file, which is where the aforementioned packet retransmission schemes are used.

When given a situation where the amount of content due to be pushed through a connection is growing at a rate greater than it is possible to push through that connection, also known as a bottleneck, then there is no other solution than to drop packets. The TCP protocol is designed with a slow-start connection strategy so that excessive packet loss will cause the sender to throttle back and stop flooding the bottleneck point with data (using perceived packet loss as feedback to discover congestion). The data packets will be transmitted over a longer duration.

There are many methods used for determining which packets to drop. Most basic networking equipment will use FIFO queuing for packets waiting to go through the bottleneck and they will drop the packet if the queue is full at the time the packet is received. This type of packet dropping is called tail drop. However, dropping packets when the queue is full is a poor solution for any connection that requires real-time throughput. In cases where quality of service is rate limiting a connection, packets may be intentionally dropped in order to slow down specific services to ensure available bandwidth for other services marked with higher importance (like those used in the leaky bucket algorithm). For this reason, packet loss is not necessarily an indication of poor connection reliability or a bottleneck.

Packet loss is closely associated with quality of service considerations, and is related to the erlang unit of measure.

As a rule of thumb derived from day-to-day practical experience, in general with TCP/IP protocols a packet loss below 0.1% (1 lost packet in every 1000 packets) can be tolerated; anything higher will have more or less impact (depending on circumstances) and needs to be addressed.