Notes on implementing RED with ATM: Sally Floyd, October 1995. Computing the average queue size in hardware: This could be done in the background. This would also avoid the messy software algorithm in the paper for taking account of queue idle times. What to do when we detect the first cell of a new packet, and the average queue size is between the min and max queue threshold (that is, we have to decide whether or not to drop that packet): One possibility would be to count arriving packets (via counting the first cell of each arriving packet). One could increment the counter once for each arriving packet, and then decide (quickly) whether to drop that packet. The second possibility, when there was less danger of immediate buffer overflow, would be to (effectively) increment the counter for each arriving cell, and therefore to have each cell be equally likely to be marked. And then when a cell was marked, the switch would wait to discard the next arriving complete packet of cells for that VC. In this way, the chance of a VC being marked would be proportional to the number of arriving cells for that VC, not to the number of arriving packets. An intermediate strategy would be, when the first cell of a new packet arrives, to "weight" that packet by the number of cells in either this packet or the previous packet on that VC (if something like that is easy to find out about). In this way, you could still have the chance that a VC is marked be proportional to the number of arriving cells rather than the number of arriving packets, and at the same time be asking the question "should I drop this packet", rather than "should I drop the next packet that arrives for this VC"? RED allows you to have a large buffer to accomodate transient congestion, while ensuring that the large buffer won't be full all of the time. In doing this, RED ensures that most packet drops are "controlled" drops, not drops that are forced by a buffer overflow. So RED would also work well in conjunction with a packet-discard strategy for ATM switches.