Re: TCP Checksum Interoperability

der Mouse <mouse@Rodents.Montreal.QC.CA> Sat, 06 April 2002 03:01 UTC

Date: Fri, 5 Apr 2002 22:01:58 -0500 (EST)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200204060301.WAA02959@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: tcp-impl@grc.nasa.gov
Subject: Re: TCP Checksum Interoperability
In-Reply-To: <3CAE4F6F.3090701@isi.edu>
References: <200204052209.RAA13008@ginger.lcs.mit.edu> <200204060021.TAA24631@Sparkle.Rodents.Montreal.QC.CA> <3CAE4F6F.3090701@isi.edu>
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 2209
Lines: 45

>> ...huh?  It depends on how you implement one's-complement arithmetic.
> See RFC1624.

I believe 1624 is wrong, because it makes exactly the same mistake
you're making here.  What's more, to quote from it, "This memo does not
specify an Internet standard of any kind".

> The definition of 1's complement arithmetic is not implementation
> dependent.

True as far as it goes.  But in abstract one's-complement binary
arithmetic, all-0-bits and all-1-bits are completely equivalent, both
on input and on output; an implementation may produce either, at whim,
for zero results, and still be computing with one's-complement
arithmetic.

_That_ arithmetic is the one that is "not implementation dependent".  I
believe that's the arithmetic 793 specifies - and in that arithmetic,
the difference between all-0-bits and all-1-bits is a matter of two
completely equivalent representations of a single semantic value;
either may be generated for a zero result, according to convenience of
implementation, the parity of the cycle counter, or whether the CPU
happens to be mounted vertically.

>> Trying to draw an artificial distinction between them is not only
>> unsupported by the standard as far as I can tell but liable to break
>> interoperability with conformant implementations which don't draw
>> that distinction.
> That issue is covered in RFC1624 and in RFC768.

1624, aside from being all about *incremental* computation, is, I
believe, simply wrong; the arithmetic it describes - wherein all-0-bits
and all-1-bits are different - is not one's-complement arithmetic.

768 is irrelevant, since we're discussing TCP, and also because it
specifically goes to the trouble of specifying one of the two otherwise
equivalent representations of zero - it standardizes, for purposes of
UDP, a semantic difference somewhat akin to the one you're trying to
read into 793, which I believe just isn't there.  That is, 768 is
describing not one's-complement arithmetic but a specifically and
narrowly tailored extension of one's-complement arithmetic.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B