home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.ee.lbl.gov
/
2014.05.ftp.ee.lbl.gov.tar
/
ftp.ee.lbl.gov
/
email
/
red_atm.notes
< prev
next >
Wrap
Text File
|
1996-05-29
|
2KB
|
40 lines
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.