home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / protocol / tcpip / 4378 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  1.6 KB
  1. Xref: sparky comp.protocols.tcp-ip:4378 comp.protocols.misc:688 comp.protocols.iso:1120
  2. Path: sparky!uunet!think.com!barmar
  3. From: barmar@think.com (Barry Margolin)
  4. Newsgroups: comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso
  5. Subject: Re: Why sequence number on bytes instead of packets?
  6. Date: 10 Sep 1992 21:09:16 GMT
  7. Organization: Thinking Machines Corporation, Cambridge MA, USA
  8. Lines: 22
  9. Message-ID: <18odhsINNhvr@early-bird.think.com>
  10. References: <STEINAR.HAUG.92Sep10201931@delab.sintef.no>
  11. NNTP-Posting-Host: telecaster.think.com
  12.  
  13. In article <STEINAR.HAUG.92Sep10201931@delab.sintef.no> Steinar.Haug@delab.sintef.no (Steinar Haug) writes:
  14. >I have sort of grown up with TCP/IP, and I feel comfortable with the notion
  15. >of having sequence numbers on bytes, instead of on packets. I have always
  16. >assumed this was to make the fragmentation/reassembly process easier. 
  17.  
  18. Fragmentation/reassembly takes place in IP, but sequence numbers are in
  19. TCP, so they don't have anything to do with each other.
  20.  
  21. >What are the arguments for sequence numbers on bytes instead of packets,
  22. >given that the protocol in question will *not* have fragmentation?
  23.  
  24. When building streams out of datagrams, using byte-oriented sequence
  25. numbers means that you don't have to retransmit exactly the same packet.
  26. You can buffer up packets waiting to be retransmitted, and retransmit them
  27. as a whole rather than in the original separate packets.  This reduces the
  28. number of packets that have to be sent during retransmission, although it
  29. may increase the total amount of retransmitted data.
  30. -- 
  31. Barry Margolin
  32. System Manager, Thinking Machines Corp.
  33.  
  34. barmar@think.com          {uunet,harvard}!think!barmar
  35.