home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9775 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.8 KB
  1. Path: sparky!uunet!sun-barr!cs.utexas.edu!wupost!uwm.edu!rutgers!igor.rutgers.edu!athos.rutgers.edu!hedrick
  2. From: hedrick@athos.rutgers.edu (Charles Hedrick)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Linux-Activists Digest #86
  5. Message-ID: <Sep.3.15.59.08.1992.12430@athos.rutgers.edu>
  6. Date: 3 Sep 92 19:59:10 GMT
  7. References: <1992Sep3.171836.4151@athena.mit.edu>
  8. Organization: Rutgers Univ., New Brunswick, N.J.
  9. Lines: 41
  10.  
  11. allredkl@choc01.dnet.dupont.com (Kevin L. Allred, 615-875-7167) writes:
  12.  
  13. >1% packet loss.  I exchanged mail with Ross Biro about the problem,
  14. >and he told me that current linux TCP/IP code doesn't slow down the
  15. >rate at which it send packets even when it receives a signal from the
  16. >router to do so.  He says that the linux host is probably overloading
  17. >the router with packets, thus producing hung connections.  He
  18. >suggested a temporary solution that works by cripling the server so it
  19. >can't send packets too fast, but I am reluctant to try this approach.
  20.  
  21. >A better approach would be to fix the server so it payes attention to
  22. >router signals to slow down.  I looked at the net source code for a
  23. >a little while, but it was clear that it is going to take deep
  24. >understanding to add this type capability.
  25.  
  26. Actually, the current feeling among TCP/IP experts is that it's a
  27. mistake to pay attention to ICMP source quench, which I assume is what
  28. you're referring to.  Instead, you want to keep track of round trip
  29. times and packet loss rates, and set your retransmission times and
  30. local window based on them.  There's a fairly simple set of code from
  31. Van Jacobson to do this.  These algorithms are now used in most TCP
  32. implementations.  Currently it looks like the Linux TCP doesn't
  33. compute round trip times at all.  I assume it's got a hardwired RTT
  34. that is appropriate for Ethernet.  The SLIP implementation that people
  35. are working on is going to have to fix this, or they're going to get
  36. very odd results.
  37.  
  38. The necessary algorithms are listed in the TCP section of RFC 1122.
  39. Those point to other references that document them in detail.  Note
  40. that these algorithms are specified with a MUST, so implementation of
  41. them is not optional.  I assume the current situation with Linux TCP
  42. is due to the fact that it's still a pre-release version, and that no
  43. one intends to release it without appropriate congestion avoidance and
  44. slow start code.  Fortunately, the code is fairly easy.  It should not
  45. require any restructuring of the current implementation, though it
  46. will require some additional variables.  Certainly any new TCP/IP
  47. implementations should conform to RFC's 1122 and 1123 before official
  48. release.  I believe it would be highly unfriendly to use any
  49. implementation not having these algorithms on any network beyond a
  50. local Ethernet or a set of Ethernets connected via links that at
  51. least T1.
  52.