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
- RE: TCP Checksum Interoperability Michael Smith
- RE: TCP Checksum Interoperability Michael Smith
- Re: TCP Checksum Interoperability Michael Smith
- Re: TCP Checksum Interoperability Joe Touch
- Re: TCP Checksum Interoperability Ignacio Goyret
- RE: TCP Checksum Interoperability Lloyd Wood
- RE: TCP Checksum Interoperability Lloyd Wood
- Re: TCP Checksum Interoperability Rob Austein
- Re: TCP Checksum Interoperability J. Noel Chiappa
- Re: TCP Checksum Interoperability Lloyd Wood
- Re: TCP Checksum Interoperability Rob Austein
- Re: TCP Checksum Interoperability Matt Crawford
- Re: TCP Checksum Interoperability Alan Cox
- Re: TCP Checksum Interoperability Lloyd Wood
- Re: TCP Checksum Interoperability Lloyd Wood
- Re: TCP Checksum Interoperability der Mouse
- Re: TCP Checksum Interoperability der Mouse
- Re: TCP Checksum Interoperability vint cerf
- Re: TCP Checksum Interoperability Fred Baker
- Re: TCP Checksum Interoperability Joe Touch
- Re: TCP Checksum Interoperability der Mouse
- RE: TCP Checksum Interoperability Chris Trobridge
- RE: TCP Checksum Interoperability Bob Braden