home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / nfs / 3035 next >
Encoding:
Internet Message Format  |  1993-01-04  |  4.1 KB
  1. Path: sparky!uunet!spool.mu.edu!hri.com!noc.near.net!vaxeline.ftp.com!cream.ftp.com!jbvb
  2. From: jbvb@vax.ftp.com (James B. VanBokkelen)
  3. Newsgroups: comp.protocols.nfs
  4. Subject: Re: NFS packet size
  5. Keywords: TCP NFS
  6. Message-ID: <930104123326@cream.ftp.com>
  7. Date: 4 Jan 93 17:33:26 GMT
  8. References: <u97b4fc@rhyolite.wpd.sgi.com> <C04t4o.K10@news.iastate.edu> <1993Jan1.115015.17311@prl.dec.com> <ubeuj2s@rhyolite.wpd.sgi.com>
  9. Sender: root@vaxeline.ftp.com (vaxeline.ftp.com root account)
  10. Reply-To: jbvb@ftp.com
  11. Organization: FTP Software, Inc., Wakefield, MA
  12. Lines: 65
  13. Nntp-Software: PC/TCP NNTP
  14. Nntp-Posting-Host: whipped-cream.ftp.com
  15.  
  16. In article <ubeuj2s@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  17.  
  18.     In article <1993Jan1.115015.17311@prl.dec.com>, boyd@prl.dec.com (Boyd Roberts) writes:
  19.     > ...
  20.     > > A dropped TCP fragment can result in a large amount of resending too.
  21.     > 
  22.     > True, but that all happens at the TCP/IP level which is far more
  23.     > responsive than NFS's 1, 2, 4, 8 ... _second_ exponential backoff
  24.     > when a datagram gets lost.
  25.     
  26.     In other implementations of NFS, the NFS timeout starts at 0.7 seconds
  27.     not 1.0, and can be reduced to 0.1 seconds.  Please compare 0.1 seconds
  28.     with the standard TCP timeouts.
  29.  
  30. In a good TCP (or a good UDP NFS), retransmit timeouts are adaptive.
  31. Whether it's TCP or NFS over UDP, what you want for a floor on the
  32. adaptive algorithm depends on your timer granularity, but it *really*
  33. ought to be larger than the average Round Trip Time plus the standard
  34. deviation of the RTT.
  35.  
  36. In most UDP NFS traffic I've watched, the standard deviation of the
  37. server's response time is large, a significant fraction of a second.
  38. Presumably this is due to disk contention and cache hit/miss/invalidation.
  39. What this implies is that you'll benefit from having your network RTT
  40. decoupled from the disk, which TCP provides.  As long as TCP is happy
  41. with the connection, there's no reason to retry the RPC...
  42.  
  43.     > We had a flakey drop cable here a while back.  When it was bad it would
  44.     > take in the order of a minute to write an 8K block.  You could see the
  45.     > fragments being dropped and the NFS retries.  I _never_ want to see
  46.     > that again -- it was _awful_.
  47.     
  48.     It could have been as bad or worse if you had been using NFS or TCP.
  49.     Your TCP connections would have been timing-out and being recreated,
  50.     throwing away any successfully moved data, and forcing the systems to
  51.     attempt the extra packet exchanges that are required to start a TCP
  52.     connection, incurring even more grief.
  53.  
  54. If you're actually losing enough packets to make a good TCP drop a
  55. connection due to timeouts (25%+), you won't get any UDP NFS I've ever
  56. seen to work at all.  If your TCP drops connections with 10% packet loss,
  57. you've got one or more of the 4bsd "escalating retransmit timeout" bugs,
  58. and should get it fixed.
  59.  
  60.     With large (e.g. 250KByte) or even just full sized (e.g. 60KB) TCP
  61.     windows, TCP can involve the retransmission of far more than an 8KB UDP
  62.     packet.  The advantage with TCP is that its "go back N" retransmission
  63.     scheme only goes back to the first lost TCP segment, not the to start
  64.     of the NFS request.  You can hope to continually make progress, to only
  65.     be thrown back to the start of the effort when things get really bad.
  66.  
  67. A good TCP buffers most or all of the ahead-of-sequence segments, so at
  68. best you only need to retransmit the one that was lost.  Even if you can
  69. control the IP ID on an outgoing UDP NFS packet, you still need to re-send
  70. the whole thing, because as you say you can't tell what's missing.  The
  71. issue is discussed in detail in Kent & Mogul's "Fragmentation Considered
  72. Harmful" (ACM Computer Communications Review Vol. 17 #5).
  73.  
  74. So, what is "a good TCP"?  One derived from 4.3 tahoe or later is fairly
  75. good, but it may still mis-handle ICMP errors, or escalate its retransmit
  76. timeout in the face of packet loss.  I don't know of any objective tests,
  77. so reading RFC 793 and watching it perform in the face of adversity is
  78. still the best way to find out.
  79.  
  80. James B. VanBokkelen        2 High St., North Andover, MA  01845
  81. FTP Software Inc.        voice: (508) 685-4000  fax: (508) 794-4488
  82.