Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ucla-cs!ames!ucbcad!ucbvax!AI.AI.MIT.EDU!JBVB
From: JBVB@AI.AI.MIT.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: TCP/IP header question
Message-ID: <168645.870314.JBVB@AI.AI.MIT.EDU>
Date: Sat, 14-Mar-87 18:59:45 EST
Article-I.D.: AI.168645.870314.JBVB
Posted: Sat Mar 14 18:59:45 1987
Date-Received: Sun, 15-Mar-87 07:36:02 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 21
Approved: tcp-ip@sri-nic.arpa

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.