jbvb@BORAX.LCS.MIT.EDU.UUCP (03/11/87)
I don't see any reason to send obsolete information; our implementation updates both ACKs and Window to the values current at the instant the packet is sent. Of course, this does mean we have to re-checksum the packet, but we have to do this anyway if a packet gets partially ack'ed (which you'd better be prepared for...) Note that it *does* seem like a good idea (not mine) to retain the IP 'identification' so that fragments can be assembled from any instance of (re)transmission of a given packet. jbvb@ai.ai.mit.edu James B. VanBokkelen FTP Software, Inc.
braden@ISI.EDU.UUCP (03/15/87)
If two instances of a given IP datagram contain TCP segments with differing TCP headers, you may be able to reassemble them but it won't do much good... presumably the
JBVB@AI.AI.MIT.EDU.UUCP (03/15/87)
Bob, I only got the first few sentences of your message. What I see looks like a point I hadn't thought about. If the TCP header has changed, then using the same IP identification is counter-productive. In conventional implementations, I suppose it is up to the individual designer or tuner to decide whether the fragment reassembly potential is worth the cost of re-sending obsolete Window and Ack. Our current TCP sends the up-to-date information. An idea struck me, though: How about using some sort of checksum of the data passed to IP (perhaps with the protocol and port number appended to prevent aliasing) as the identification? This would seem to be a simple way of getting the reassembly automatically whenever it was possible, without making an arbitrary upper layer concern itself with IP internals. I know, this is easy for me to say, with the processor all to myself, but... jbvb@ai.ai.mit.edu James B. VanBokkelen FTP Software Inc.
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (03/16/87)
Date: Tue, 10 Mar 87 23:09:57 est
From: jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen)
I don't see any reason to send obsolete information; our
implementation updates both ACKs and Window to the values current at
the instant the packet is sent. Of course, this does mean we have to
re-checksum the packet, but we have to do this anyway if a packet gets
partially ack'ed (which you'd better be prepared for...)
Nit: Indeed, you'd better be prepared for it, but you don't have to
rechecksum if you don't reshuffle the data around. Not reshuffling is
paramount to sending old+new data, which the spec allows.
Note that it
*does* seem like a good idea (not mine) to retain the IP
'identification' so that fragments can be assembled from any instance
of (re)transmission of a given packet.