home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / protocol / tcpip / 6056 < prev    next >
Encoding:
Text File  |  1993-01-22  |  2.0 KB  |  45 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!destroyer!fmsrl7!lynx.unm.edu!nmsu.edu!amolitor
  3. From: amolitor@nmsu.edu (Andrew Molitor)
  4. Subject: Re: Large Windows and Delayed Acking
  5. Message-ID: <1993Jan22.162817.3224@nmsu.edu>
  6. Sender: usenet@nmsu.edu
  7. Organization: Department of Mathematics
  8. References: <1993Jan21.233655.29402@gordian.com>
  9. Date: Fri, 22 Jan 1993 16:28:17 GMT
  10. Lines: 33
  11.  
  12. In article <1993Jan21.233655.29402@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
  13. >
  14. >  What I have found is that with large windows (say 16kb) the sending
  15. >TCP stops sending at about 4k and waits for the receiving TCP to
  16. >send an ACK. The receiving TCP, however is using a defered acking
  17. >scheme which tries to delay sending ACK until a larger window is
  18. >consolidated into one packet. The metric it is using is 1/2 the
  19. >buffer size, and the delayed ack period is on the order of 100ms.
  20. >  I can understand why a sending TCP might be leary of sending *so*
  21. >much data without hearing an ack, but my question is what algorithm
  22. >is the sending TCP using to determine how much data it will send
  23. >before going into this quiesent state? Is there an appropriate
  24. >RFC which I should read which describes this situation? Is the
  25. >behavior of the sending TCP correct?
  26.  
  27.     Sounds like the sender's computing a congestion window
  28. around 4K. See, say, Steven's _Internetworking with TCP/IP_ or
  29. probably rfc793 somewhere or other. Steven's has a good exposition.
  30.  
  31.     The point is that TCP makes a guess at a good sending
  32. window size based on latency of packets, and uses the minimum
  33. of that window size and the remote's advertisement as the real
  34. window. This is used to avoid congestion. It might even be that
  35. the delayed ACK cause the sender to compute an artificially
  36. small congestion window (4K seems small to me).
  37.  
  38.     One must keep in mind that TCP is polite. If the goal is
  39. to hammer your media to death, TCP is the wrong protocol. Not, by
  40. the way, to suggest that this is your goal.
  41.  
  42.     Andrew
  43.  
  44. >        Michael Thomas    (mike@gordian.com)
  45.