Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!mcnc!ece-csc!ncrcae!ncr-sd!hp-sdd!hplabs!ucbvax!G.BBN.COM!CLYNN
From: CLYNN@G.BBN.COM
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP performance limitations
Message-ID: <[G.BBN.COM].5-Oct-87.16:28:51.CLYNN>
Date: Mon, 5-Oct-87 16:28:00 EDT
Article-I.D.: <[G.BBN.COM].5-Oct-87.16:28:51.CLYNN>
Posted: Mon Oct  5 16:28:00 1987
Date-Received: Thu, 8-Oct-87 06:37:41 EDT
References: <MAB%CORNELLC.BITNET@WISCVM.WISC.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 13

Mark,
	One could, given suitable hardware, etc. compute the checksum more
than 16 bits at at time - e.g., use 32-bit arithmetic (or some other higher
number).  There are at least two ways - adding 16 bits into a wider accumulator
which reduces/eliminates checking for carry/overflow, or adding 32 bits at a
time into the accumulator, reducing the number of memory fetches/adds/carry
checks by a factor of 2 (more if you have 64 bit arithmetic, etc.).
	One can also compute the checksum as the data is being placed
into the packet, instead of computing it after the packet has been "built".
	On retransmissions/repacketizations, one can "update" the checksum
(subtract out the old (header) values and add in the new) instead of
recomputing the sum of the data each time (the checksum is weak enough that
byte-pair position, order of summation, etc. doesn't matter).