home *** CD-ROM | disk | FTP | other *** search
/ ftp.ee.lbl.gov / 2014.05.ftp.ee.lbl.gov.tar / ftp.ee.lbl.gov / email / sf.98mar11.txt < prev    next >
Text File  |  1998-03-10  |  2KB  |  56 lines
  1. To: Subramaniam Vincent <svincent@kentrox.com>
  2. cc: end2end-interest@ISI.EDU
  3. Subject: Re: RED with drop from front 
  4. Date: Wed, 11 Mar 1998 16:30:34 PST
  5. From: Sally Floyd <floyd>
  6.  
  7. Subramaniam -
  8.  
  9. >Has anybody experimented with RED and "drop from front/head" strategy ? 
  10.  
  11. I haven't experimented with drop from front with RED, but I don't think
  12. it would be a problem.  (I don't think it would be a big win,
  13. particularly since with RED the average queue size is usually small.
  14. But I don't think it would hurt, either.)
  15.  
  16. When operating RED in byte mode, and taking into account the size of a packet
  17. in bytes when deciding the probability with which that packet should be dropped,
  18. you have to make sure that you are looking at the size in bytes of the packet that
  19. you are actually considering dropping.  But other than that, I assume that
  20. it would all be completely straightforward.
  21.  
  22. - Sally
  23.  
  24. -------------------------------------------
  25.  
  26.  
  27. Subject: Re: RED
  28. Date: Thu, 10 Jul 97 14:51:51 PDT
  29. From: Sally Floyd <floyd>
  30.  
  31. ...
  32. >Is there any particular reason why RED drops the incoming packet instead of
  33. >the packet at the head of the queue?
  34.  
  35. Mostly that I haven't thought about it much.  I have assumed
  36. that it was easier for routers to drop arriving packets than to drop
  37. packets at the head of the queue.  But if all packets were the
  38. same size, it would be fairly easy to drop packets
  39. at the head of the queue, I think.  
  40.  
  41. When all of the packets are not the same size, it might be a little
  42. tricky.  You would have to make sure you weren't measuring arriving
  43. packets, and dropping packets at the head of the queue, and 
  44. inappropriately discriminating against packets of some size.
  45.  
  46. But mainly, when RED is working right the average queue size should be small,
  47. and it shouldn't make too much different one way or another whether
  48. you drop a packet at the front of the queue or at the tail, I think.  
  49. The RED congestion indication is not an indication of imminent
  50. buffer overflow, but part of some regular steady-state indication to
  51. the various end nodes to reduce their arriving rates at appropriate staggered
  52. times.
  53.  
  54. - Sally
  55.  
  56.