Packet loss

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Packet loss occurs when one or more packets of data travelling across a computer network fail to reach their destination.

Causes[edit]

Packet loss can be caused by a number of factors including signal degradation over the network medium due to multi-path fading, packet drop because of channel congestion,[1][2] corrupted packets rejected in-transit, faulty networking hardware, faulty network drivers, or normal routing routines (such as DSR in ad hoc networks [3]). Packet loss can also happen intentionally through network dissuasion technique for operational management purposes.[4]

Effects[edit]

When caused by network problems, lost or dropped packets can result in highly noticeable performance issues or jitter with streaming technologies, voice over IP, online gaming and videoconferencing, and will affect all other network applications to a degree.[5] However, it is important to note that packet loss does not always indicate a problem. If the latency and the packet loss at the destination hop are acceptable then the hops prior to that one don't matter.[6]

Packet recovery[edit]

Some network transport protocols such as TCP provide for reliable delivery of packets. In the event of packet loss, the receiver asks for retransmission or the sender automatically resends any segments that have not been acknowledged.[7] Although TCP can recover from packet loss, retransmitting missing packets causes the throughput of the connection to decrease. This drop in throughput is due to the sliding window protocols used for acknowledgment of received packets. In certain variants of TCP, if a transmitted packet is lost, it will be re-sent along with every packet that had been sent after it. This retransmission causes the overall throughput of the connection to drop.

Protocols such as UDP provide no recovery for lost packets. Applications that use UDP are expected to define their own mechanisms for handling packet loss.

Acceptable packet loss[edit]

“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.” [8] The amount of packet loss that is acceptable depends on the type of data being sent. For example, for Voice over IP traffic, “[m]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.”[9] 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 option than to drop packets.[10] 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).[11] 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 undesirable 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 2.5% (25 lost packet in every 1000) can be tolerated; anything higher will have more or less impact (depending on circumstances) and needs to be addressed.[12][not in citation given]

See also[edit]

References[edit]

  1. ^ Kurose, J. F. & Ross, K. W. (2010) Computer Networking: A Top-Down Approach. New York: Addison-Wesley. P 30.
  2. ^ Kurose, J. F. & Ross, K. W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. P 30.
  3. ^ Perkins, C. E. (2001). Ad Hoc Networking. Boston: Addison-Wesley. P 147.
  4. ^ "Controlling Applications by Managing Network Characteristics" Vahab Pournaghshband, Leonard Kleinrock, Peter Reiher, and Alexander Afanasyev ICC 2012
  5. ^ Kurose, J. F. & Ross, K. W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. P 602.
  6. ^ "Packet loss or latency at intermediate hops." (HTTP). Retrieved 2007-02-25. 
  7. ^ Kurose, J. F. & Ross, K. W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. P 242.
  8. ^ Kurose, J. F. & Ross, K. W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. P 42-43.
  9. ^ Mansfield, K. C. & Antonakos, J. L. (2010). Computer Networking from LANs to WANs: Hardware, Software, and Security. Boston: Course Technology, Cengage Learning. P501.
  10. ^ Kurose, J. F. & Ross, K. W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. P 30.
  11. ^ Kurose, J. F. & Ross, K. W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. P 282-283
  12. ^ http://sdu.ictp.it/pinger/pinger.html

External links[edit]