Packet loss

Packet loss occurs when one or more packets of data travelling across a computer network fail to reach their destination. Packet loss
is typically caused bynetwork congestion. Packet loss is measured as a percentage of packets lost with respect to packets sent.

The Transmission Control Protocol(TCP) detects packet loss and performs retransmissions to ensure reliable messaging. Packet loss
in a TCP connection is also used toavoid congestion and thus produces an intentionally reducedthroughput for the connection.

In streaming media and online game applications, packet loss can affect the user experience.

Contents
1 Causes
2 Effects
3 Measurement
4 Acceptable packet loss
5 Diagnosis
6 Rationale
7 Packet recovery for reliable delivery
8 Impact of queuing discipline
9 See also
10 References
11 External links

Causes
Packet loss is typically caused by network congestion. When content arrives for a sustained period at a given router or network
segment at a rate greater than it is possible to send through, then there is no other option than to drop packets.[1] If a single router or
link is constraining the capacity of the complete travel path or of network travel in general, it is known asbottleneck.
a

Packet loss can be caused by a number of other factors that can corrupt or lose packets in transit, such as radio signals that are too
weak due to distance ormulti-path fading, faulty networking hardware, or faulty network drivers.

[2] Packet loss can also be caused by apacket drop attack.

In some cases, packets are intentionally dropped by routing routines.

Effects
Packet loss can reduce throughput for a given sender, whether unintentionally due to network malfunction, or intentionally as a
means to balance available bandwidth between multiple senders when a given router or network link reaches nears its maximum
capacity.[3]

When reliable delivery is necessary, packet loss increases latency due to additional time needed for retransmission. Assuming no
retransmission, packets experiencing the worst delays might be preferentially dropped (depending on the queuing discipline used)
resulting in lower latency overall at the price of data loss.
During typical network congestion, not all packets in a stream are dropped. This means that undropped packets will arrive with low
latency compared to retransmitted packets, which arrive with high latency. Not only do the retransmitted packets have to travel part
of the way twice, but the sender will not realize the packet has been dropped until it either fails to receive acknowledgement of
receipt in the expected order, or fails to receive acknowledgement for a long enough time that it assumes the packet has been dropped
as opposed to merely delayed.

Measurement
Packet loss may be measured as frame loss rate defined as the percentage of frames that should have been forwarded by a network
but were not.[4]

Acceptable packet loss

Packet loss is closely associated withquality of service considerations, and is related to theerlang unit.

The amount of packet loss that is acceptable depends on the type of data being sent. For example, for voice over IP traffic, one
commentator reckoned that "[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."[5] Another described less than 1% packet loss as
"good" for streaming audio or video, and 1-2.5% as "acceptable".[6] 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 why a reliable delivery protocol would be used for this
purpose (to retransmit dropped packets).

Diagnosis
Packet loss is detected by application protocols such as TCP, but when a person such as a network administrator needs to detect and
diagnose packet loss, they typically use a purpose-built tool. Many routers have status pages or logs, where the owner can find the
number or percentage of packets dropped over a particular period.

For remote detection and diagnosis, theInternet Control Message Protocolprovides an "echo" functionality, where a special packet is
transmitted that always produces a reply after a certain number of network hops, from whichever node has just received it. Tools such
as ping, traceroute, and MTR use this protocol to provide a visual representation of the path packets are taking, and to measure packet
loss at each hop.

In some cases, these tools may indicate drops for packets that are terminating in a small number of hops, but not those making it to
the destination. For example, routers may give echoing of ICMP packets low priority and drop them preferentially in favor of
spending resources on genuine data; this is generally considered an artifact of testing and can be ignored in favor of end-to-end
results.[7]

Rationale
The Internet Protocol (IP) is designed according to the end-to-end principle as a best-effort delivery service, with the intention of
keeping the logic routers must implement as simple as possible. If the network made reliable delivery guarantees on its own, that
would require store and forward infrastructure, where each router devoted a significant amount of storage space to packets while it
waited to verify that the next node properly received it. A reliable network would not be able to maintain its delivery guarantees in
the event of a router failure. Reliability is also not needed for all applications. For example, with a live audio stream, it is more
important to deliver recent packets quickly than to ensure that stale packets are eventually delivered. An application may also decide
to retry an operation that is taking a long time, in which case another set of packets will be added to the burden of delivering the
original set. Such a network might also need a command and control protocol for congestion management, adding even more
complexity.
To avoid all of these problems, the Internet Protocol allows for routers to simply drop packets if the router or a network segment is
too busy to deliver the data in a timely fashion, or if the IPv4 header checksum indicates the packet has been corrupted. Obviously
this is not ideal for speedy and efficient transmission of data, and is not expected to happen in an uncongested network.[3] Dropping
of packets acts as an implicit signal that the network is congested, and may cause senders to reduce the amount of bandwidth
consumed, or attempt to find another path. For example, the Transmission Control Protocol (TCP) is designed 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).[8]

Packet recovery for reliable delivery

The Internet Protocol leaves responsibility for any retransmission of dropped packets, or "packet recovery" to the endpoints - the
computers sending and receiving the data. They are in the best position to decide whether retransmission is necessary, because the
application sending the data should know whether speed is more important than reliability, whether a message should be re-attempted
in whole or in part, whether or not the need to send the message has passed, and how to vary the amount of bandwidth consumed to
account for any congestion.

Some network transport protocols such as TCP provide endpoints an easy way to ensure reliable delivery of packets, so that
individual applications don't need to implement logic for this themselves. In the event of packet loss, the receiver asks for
retransmission or the sender automatically resends any segments that have not been acknowledged.[9] 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 User Datagram Protocol (UDP) provide no recovery for lost packets. Applications that use UDP are expected to
define their own mechanisms for handling packet loss.

Impact of queuing discipline

There are many queuing disciplines 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. Other full queue mechanisms include random eviction or weighted random
eviction. Dropping packets is undesirable as the packet is either lost or must be retransmitted and this can impact real-time
throughput; however, increasing the buffer size can lead to bufferbloat which has its own impact on latency and jitter during
congestion.

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.

See also
Bit slip
Goodput
Packet collision
Packet loss concealment
Traffic shaping

References
1. Kurose, J.F. & Ross, K.W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. p. 36.
 2. Perkins, C.E. (2001). Ad Hoc Networking. Boston: Addison-Wesley. p. 147.
3. Kurose, J.F.; Ross, K.W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. pp. 42–
43. "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."
4. RFC 1242
5. Mansfield, K.C. & Antonakos, J.L. (2010).Computer Networking from LANs to WANs: Hardware, Software, and
Security. Boston: Course Technology, Cengage Learning. p. 501.
6. http://sdu.ictp.it/pinger/pinger.html
7. "Packet loss or latency at intermediate hops"(http://www.nessoft.com/kb/24). Retrieved 2007-02-25.
8. Kurose, J.F. & Ross, K.W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. p. 282-
283.
9. Kurose, J.F. & Ross, K.W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. p. 242.

External links
Interactive animation of TCP fast retransmit simulation: packet loss detection and recovery
.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Packet_loss&oldid=805523021

"

This page was last edited on 15 October 2017, at 23:15.

Text is available under theCreative Commons Attribution-ShareAlike License ; additional terms may apply. By using this
site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of theWikimedia
Foundation, Inc., a non-profit organization.