Definition
Packet Drop Policy is the policy used by devices such as routers, base stations, and gateways to decide which packets to discard when buffers overflow or congestion occurs. A reasonable policy can prevent global synchronization, ensure high-priority services, and work with congestion control algorithms to achieve fairness and efficiency. Together with priority QoS, QoS mechanisms, and differentiated services, it forms end-to-end congestion and packet loss management.
Typical Policies
Tail Drop
Discard newly arrived packets when the queue is full. It is simple to implement but prone to TCP global synchronization, causing large throughput fluctuations.
RED (Random Early Detection)
Drop packets probabilistically when the queue is not full; the probability increases with queue length to trigger congestion control early and avoid burst packet loss.
WRED (Weighted RED)
Set different drop thresholds and probabilities based on DSCP/priority, with higher-priority traffic being dropped later to achieve differentiation.
Priority dropping
Preferentially drop lower-priority queues (such as BE traffic) during congestion, prioritizing critical services like EF and AF.
Relationship with ECN
ECN (Explicit Congestion Notification) allows routers to mark congestion via the IP/CP header without dropping packets. The terminals and sender can adjust the rate accordingly, reducing actual packet loss. Packet loss policies can work with ECN to alleviate congestion early by marking instead of discarding.
When SimtoLink IoT devices access cellular networks, their data flows through the operator's core network and the Internet, where router and gateway packet loss policies along the way will affect end-to-end reliability. For critical commands, OTA upgrades, etc., SimtoLink recommends configuring high-priority QoS to reduce the probability of being dropped during congestion. The platform side also considers network packet loss in retransmission and acknowledgment mechanisms to ensure service reliability.
The Queue Threshold Decides Who Is Dropped
A drop policy answers which packet is discarded first when a buffer is about to overflow or already has, and when that discard happens. Tail drop is the simplest: once the queue is full, every new arrival is dropped. It is cheap to implement, but several TCP flows see a loss at the same moment, shrink their windows together, and recover together. Throughput collapses in a cycle. That is global synchronization. RED starts dropping at random before the queue is full. The probability rises with the average queue length, so senders slow down early and the last instant does not drop everything. WRED gives different priorities different minimum and maximum thresholds. High priority has to wait until the queue is longer before it starts being dropped.
The policy does not create bandwidth. It only decides which flows take the damage when congestion happens. Without classification there is no differentiation. If every packet enters the same queue, WRED weights do nothing. A drop is also not the same thing as a link bit error. A block error on the radio is a physical-layer event. A tail drop on a router is a buffer event. The counters at the two ends cannot stand in for each other.
Early Drop Suits Only Flows That Can Slow Themselves
RED and WRED work only when the sender can read a drop or an explicit congestion mark and lower its rate. Ordinary TCP can. Fixed-rate UDP, a sensor that reports on a cycle, and a serial-to-IP device with the rate written in permanently will not slow down when packets are dropped. Early drop only punches holes in them. Put that traffic in a rate limit or in its own queue. Do not expect random early drop to discipline it. Alarms and control commands at high priority should have a higher drop threshold, or sit in a strict-priority queue, so they are not packed in with a bulk retransmission.
ECN can mark the IP header before a real drop, so the endpoints slow down. Both ends and every device along the path have to support it. Otherwise the mark is ignored and the queue still walks into tail drop. A bearer priority on the cellular side has to map to the DSCP the router looks at. After an exit device rewrites the mapping, WRED drops by the wrong color. Before configuring, draw whether the mark stays consistent from the module, the base station, and the core network to the enterprise firewall, and leave a separate committed rate for bandwidth management. Do not drop only at the last hop.
One Tail-Drop Queue Carries Every Service
A common mistake is a single FIFO on the enterprise gateway, with IoT reports, remote desktop, and firmware upgrade mixed in. One upgrade burst tail-drops every control command, and the site goes off to inspect radio retransmission. Another mistake is a RED minimum threshold set above the hardware queue depth. Random early drop never happens, and congestion is still tail drop. Set the threshold too low and ordinary bursts start dropping. A short burst that could have been absorbed becomes an application retransmission.
Unlimited application retries are also used to paper over loss. Retry traffic is larger than the original traffic, the queue grows, more is dropped, and the loss is amplified. First separate a drop on the air interface, a drop in the core, and a drop in the enterprise queue. The air interface has block errors and radio retransmission counts. The enterprise queue has tail-drop counts and queue delay. Seeing only a timeout in the cloud, then raising both radio retransmission and application retry, usually makes the congestion worse.
Fixed-rate video and periodic sensors do not slow down because they were dropped. Random early drop only punches holes in them. Rate-limit those flows, or queue them separately, and leave early drop for transports that can shrink a window. If a priority threshold is set deeper than the device queue, the configuration does nothing. If it is too shallow, a normal short burst is dropped too, and application retries make the burst denser. Watch whether queue delay and drop counts rise when the service bursts, then decide whether to add bandwidth or change the threshold. If the counts do not rise and the application times out, the drop is probably on the air interface in front, not in this device’s queue.