>In fact, the current choice is optimal. If the problem is that we are
>being hit with too many packets too quickly, the most desirable course
>of action is the one which requires the least amount of computing
>power. Doing nothing to the receive queue is better than trying to
>"dequeue" some of the packets there to allow the new one to be added.
A study by Greg Finn <finn@isi.edu> determined that randomly
dropping packets in a congested queue may be preferable to dropping
only newly received packets. Dropping only newly-arrived packets can
be suboptimal, depending upon the details of how your packets are
generated, of course. YMMV.
"A Connectionless Congestion Control Algorithm"
Finn, Greg
ACM Computer Communication Review, Vol. 19, No. 5., pp. 12-31,Oct. 1989.
The way I view this result is that each packet is part of a
flow (true even for most UDP packets). Dropping a packet penalizes
the flow. All packets in a queue contribute to the queue's
congestion, not simply the most recently-arrived packet. Dropping a
random packet in the queue distributes the penalty among the flows in
the queue. Over the statistical average, this is more optimal than
dropping the latest packet.
Craig Milo Rogers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 23 2001 - 21:00:09 EST