home *** CD-ROM | disk | FTP | other *** search
/ ftp.ee.lbl.gov / 2014.05.ftp.ee.lbl.gov.tar / ftp.ee.lbl.gov / email / sf.98may7.txt < prev    next >
Text File  |  1998-05-06  |  1KB  |  35 lines
  1. To: braden@ISI.EDU
  2. Subject: Re: Source Quench
  3. Date: Thu, 07 May 1998 11:20:27 PDT
  4. From: Sally Floyd <floyd>
  5.  
  6. ...
  7.  
  8. These are all of the reasons that I can know for not doing
  9. Source Quench:
  10.  
  11. (1) It is not a general solution, particularly for multicast.  Some
  12. connections have receiver-based congestion control instead of
  13. sender-based congestion control.  (And in addition, one would not like
  14. to have a "Source Quench" implosion in a multicast tree.)
  15.  
  16. (2) Source Quench packets can be dropped, so they are not reliable.  If
  17. data packets in the forward direction carrying the CE (Congestion
  18. Experienced) bit are dropped, then the application detects packet drops
  19. and uses packet drops as an indication of congestion, so this is a
  20. robust indication of congestion.  And there are robust mechanisms that
  21. receivers can use to inform senders that a packet has been received
  22. with the CE (Congestion Experienced) bit set.
  23.  
  24. (3) Even if well-done, Source Quench packets add traffic in the
  25. reverse direction on what might be a congested path.
  26.  
  27. (4) While there are some applications/environments where it might be
  28. highly advantageous for the sender to receive some indication of
  29. congestion without having to wait a roundtrip time, this is not the
  30. common case.  This is particularly true for a environment with active
  31. queue management, which is the kind of environment that is most likely
  32. to be using some new form of congestion indication.
  33.  
  34. - Sally
  35.