home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / protocol / nagle-algorithm.txt < prev    next >
Text File  |  2020-01-01  |  3KB  |  64 lines
  1.  2-Dec-96  7:19:20-GMT,3291;000000000005
  2. Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.3/8.8.3) id CAA18414 for fdc; Mon, 2 Dec 1996 02:19:19 -0500 (EST)
  3. Date: Mon, 2 Dec 1996 02:19:19 -0500 (EST)
  4. From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
  5. Message-Id: <199612020719.CAA18414@watsun.cc.columbia.edu>
  6. To: fdc@watsun.cc.columbia.edu
  7.  
  8. Newsgroups: comp.protocols.tcp-ip
  9. Path: news.columbia.edu!news.columbia.edu!panix!feed1.news.erols.com!howland.erols.net!news-peer.gsl.net!news.gsl.net!ix.netcom.com!netcom.com!nagle
  10. From: nagle@netcom.com (John Nagle)
  11. Subject: Re: Nagle - TCP_NODELAY - transaction oriented applications
  12. Message-ID: <nagleE1r4tF.2y7@netcom.com>
  13. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  14. References: <32a27b97.86620079@philos.philosys.de> <57filf$mf2@noao.edu>
  15. Date: Sun, 1 Dec 1996 20:27:15 GMT
  16. Lines: 43
  17. Sender: nagle@netcom6.netcom.com
  18. Xref: news.columbia.edu comp.protocols.tcp-ip:46498
  19.  
  20. rstevens@noao.edu (W. Richard Stevens) writes:
  21. >> Is an application required to turn off the Nagle algorithm by setting
  22. >> TCP_NODELAY in order to get good transaction performance?
  23.  
  24. >No.  If the client writes all of its request to the server at once
  25. >(e.g., one write() or one writev()) then Nagle shouldn't be a problem.
  26.  
  27. >Where Nagle interacts with a transaction client-server is when the client
  28. >sends its request as two write()s, say a small header followed by some
  29. >data.  In that case the data won't be sent when write() is called the
  30. >second time, because of Nagle, and to make it worse, the server will
  31. >delay the ACK of the first small packet because there is nothing to send
  32. >back (until the server gets the second write).
  33.  
  34.      Having invented the thing, I suppose I should say something.
  35.  
  36.      The basic problem is that either delayed ACKs or the Nagle algorithm
  37. are OK, but the combination of the two is bad.  Historically, the Nagle 
  38. algorithm came first, and it was put in to prevent tinygram floods, typically
  39. caused by an application doing lots of 1-byte writes into a slow link.
  40. Each of those writes got blown up to a full packet, and then some of them
  41. would get dropped due to congestion, and then TCP would start retransmitting,
  42. and on slow links, the TCP connection might even time out.  In any case,
  43. you'd get a huge increase in traffic when this occured, enough to cause
  44. congestion collapse in low-bandwidth nets.  (This was back in 1983,
  45. remember.)
  46.  
  47.      Delayed ACKs went in TCP after I was out of networking, and I'm not too
  48. happy about how it was done.  A delayed ACK is a bet; it's a gamble
  49. that something will be sent in the near future on which the ACK can
  50. be piggybacked.  Sometimes you win, sometimes you lose.  Unfortunately,
  51. the way it's implemented in TCP, TCP isn't keeping score.  Properly, the
  52. ACK delay timer should be adaptive, and adjusted so that, say, 80-90%
  53. of delayed ACKs do in fact get piggybacked, rather than timing out.
  54. But in the current standard, it's a fixed timer, typically 200ms,
  55. which reflects a human scale of response time.  This is totally
  56. wrong for transaction protocols.
  57.  
  58.      Unfortunately, it's not one of those things you can fix at your end;
  59. it's the ACK timer at the other end that limits local sending performance.
  60. If you could fix both ends, though, it would work nicely.
  61.  
  62.                          John Nagle
  63.  
  64.