Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ames!ucbcad!ucbvax!QUABBIN.SCRC.SYMBOLICS.COM!DCP
From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: TCP/IP header question
Message-ID: <870316100923.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Mon, 16-Mar-87 10:09:00 EST
Article-I.D.: KOYAANIS.870316100923.9.DCP
Posted: Mon Mar 16 10:09:00 1987
Date-Received: Tue, 17-Mar-87 02:11:34 EST
References: <8703110409.AA22963@BORAX.LCS.MIT.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 16
Approved: tcp-ip@sri-nic.arpa


    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.