home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / protocol / tcpip / 6068 < prev    next >
Encoding:
Text File  |  1993-01-23  |  1.5 KB  |  37 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!spool.mu.edu!news.cs.indiana.edu!lynx.unm.edu!nmsu.edu!amolitor
  3. From: amolitor@moink.nmsu.edu (Andrew Molitor)
  4. Subject: TCP congestion/Nagle's algorithm
  5. Message-ID: <1993Jan23.113544.5652@nmsu.edu>
  6. Originator: amolitor@moink.nmsu.edu
  7. Sender: usenet@nmsu.edu
  8. Organization: Department of Mathematics
  9. Date: Sat, 23 Jan 1993 11:35:44 GMT
  10. Lines: 25
  11.  
  12.  
  13.     Darn it, I think I put my foot in my mouth. After poking
  14. through rfc896 (in which Nagle introduces his algorithm for
  15. solving the 'small packet' problem) and comparing with Karn's
  16. NOS TCP implementation, I find myself confused.
  17.  
  18.     First, I misunderstood congestion windows. My apologies
  19. to whoever it was I responded to a day or so ago, blithely
  20. dismissing throughput problems as 'sounds like a small congestion
  21. window.'
  22.  
  23.     Second, Nagle seems to be saying that a TCP should not
  24. send new data while unack'd data is outstanding, while Karn's
  25. code seems to not send new data while unack'd data is outstanding
  26. *unless* there is a max segment sized chunk to go out.
  27.  
  28.     Karn's version seems right, since it allows proper
  29. streaming, while Nagle's seems to reduce the sliding window
  30. to a stop and wait arrangement. Is Karn's algorithm in Nagle's
  31. remarks, disguised as a tacit assumption that one always sends
  32. all the data one has, in multiple segments? He seems to be implying
  33. that as soon as one gets an ack, one sends all the data one has
  34. on hand. This is still not quite Karn's implementation, I think.
  35.  
  36.     Andrew
  37.