home *** CD-ROM | disk | FTP | other *** search
/ ftp.ee.lbl.gov / 2014.05.ftp.ee.lbl.gov.tar / ftp.ee.lbl.gov / email / sf.97dec01.txt < prev    next >
Text File  |  1997-12-03  |  3KB  |  53 lines
  1. ECN and defenses against evil applications:
  2.  
  3. Date: Mon, 01 Dec 1997 16:10:21 PST
  4. From: Sally Floyd <floyd>
  5.  
  6. ...
  7. >Also you have no defense against an evil application that
  8. >sets ECN-capable on but doesn't slow down when ECN is applied.
  9. >So in the domain below the "high" threshold an evil application's
  10. >best bet is to set ECN-capable and send as much as it can.
  11. >The worst case is that this forces the network into drop
  12. >mode, i.e. no worse than today for the evil application.
  13. >
  14. >So as far as I can see ECN can be defeated by evil applications
  15. >in a way that RED can't. Which means that you certainly have
  16. >to write a security considerations section about denial of
  17. >service and theft of service by misuse of ECN-capable.
  18.  
  19. I think that the issue of evil applications is quite serious.
  20. I have a draft of a paper-in-progress, "Router Mechanisms to Support
  21. End-to-End Congestion Control", available from my web page
  22. at http://www-nrg.ee.lbl.gov/floyd/, that is all about the
  23. need for routers to deploy mechanisms to detect and control the
  24. bandwidth of such evil applications.   One form of an evil application
  25. would be an application that did not reduce its sending rate in the
  26. presence of a 5% packet drop rate, but instead increased its sending
  27. rate slightly, sending additional FEC, to compensate for the increased
  28. drop rate.  Another form of an evil application would be a TCP
  29. application using non-conformant TCP, where the connection did not use
  30. FEC, but also did not decrease its congestion window in response to a
  31. packet drop, but just kept sending, using information in the TCP SACK
  32. option to identify dropped packets and retransmit them.  A roughly
  33. equivalent form of an evil application, in terms of its negative impact
  34. on the network, would be an application that set the ECN-Capable bit,
  35. but did not slow down in response to ECN bits.
  36.  
  37. That is, I don't think that a 5% packet drop rate, in and of itself, is
  38. a real deterrent to any application that wants to ignore congestion
  39. control.  I don't think that there are **any** deterrents in the
  40. current Internet to keep connections from ignoring congestion control
  41. (other than the fact that they will know that they are being socially
  42. unresponsible).  Somehow, it is still the case that roughly 95\% of the
  43. traffic seems to be using some form of vaguely-conformant TCP,
  44. the steady-state packet drop rate is not spiralling up to 10 or 20
  45. percent, and congestion collapse has not yet hit.  I think that we
  46. shouldn't press our luck, and I think that deterrents are indeed
  47. necessary, but I don't think that the addition of ECN makes the job of
  48. providing such deterrents any more difficult, or any more pressing.
  49. I think that the need for such deterrents is already pretty pressing...
  50.  
  51. - Sally
  52.  
  53.