Subject: RE: iSCSI: 12-97 Bit Rule

From: [email-masked]
Date: Thu, 13 Jun 2002 17:38:19 -0600

Luben,

If I ruled the world, I would number the least significant bit 0. I agree
that that is a more logical numbering. My second choice would be for the
whole world to use the same numbering even if it was different from that.
However, neither you nor I rule the world and IETF has chosen to number the
most significant bit 0 and the choices made by other organizations vary all
over the map and we get to flop and flip bits to match them to the
environment.

A convention that is used throughout the document (like the significance of
bits within a field) belongs at the front. That convention also gets
reinforced when one looks at other parts of the document like chapter 9.
That is why it is satisfactory for 1.3.1 through 1.3.3 to be at the front. A
detail that only applies one place like the different ordering of the bits
in the CRC calculation should be in the place where it is used. That is why
it wasn't good to have 11.1 reference 1.3.4 for how to order the bits in the
CRC calculation. This is just good editorial practice for building a usable
document.

On the particular text:
8) The message sent is P and appended at the end are the
   bit coefficients of CRC(x), with x^31 bit coefficient
   first, then x^30, etc.
the problem is that the x^31 bit doesn't go first when it is in the frame.
Also, bits can go through their entire existence without being sent in
serial order so nothing is first. Say which bit of the CRC goes into which
bit of the digest field and you are done.

Sincerely,
Pat

-----Original Message-----
From: Luben Tuikov [mailto:[email-masked]]
Sent: Thursday, June 13, 2002 4:13 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: iSCSI: 12-97 Bit Rule

[email-masked] wrote:
>
> TCP/IP Illustrated numbers bits with bit 0 as the
> most significant. My books on Sonet number bits
> in a byte from 1 to 8. I guess you could argue
> these are not books on computer architecture, but
> the point is that not everyone numbers bits the
> same.

Uuuh, here we go again...

Yes, I can argue that those are NOT books
on computer architecure. Let me get home
I'll send you the titles/authors/ISBN
of a few books on Computer Architecture
which use the NATURAL bit ordering:

2^(x+1) > 2^x, x >= 0,
so it only _makes_sense_ to say that
bit x+1 is more significant than bit x.

Take the number 791, is the 2rd digit
more significant than the 1nd?
Well: 791 = 7*10^2 + 9*10^1 + 1*10^0.

> If you will read 1.3.1 through 1.3.3, they do
> explicitly state the significance of bits in
> iSCSI words, half-words and bytes.

Yep, and you were complaining that it was
200 pages away from 11.1 where the CRC
digest was --- or was that in a private
email? Trying to score points?

> Julian's new description is accurate and clear.

Are you sure? Are you really sure?

> Item 8 in your description is unclear and confusing
> because the bits do not "follow" each other in the
> order you state (and any viewing of bits in a message
> as a serial stream is entirely hypothetical).

Here is 8:

8) The message sent is P and appended at the end are the
   bit coefficients of CRC(x), with x^31 bit coefficient
   first, then x^30, etc.

That is after you send P, send CRC(x) as indicated.
What doesn't follow what?

Of course it is hypothetical...

Pat, let me ask you this: Is Mathematics hypothetical?

-- 
Luben

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 13 Jun 2002 20:00:30 -0400

[email-masked] wrote:

[cheerfully deleted 0-content reply]

> bit of the digest field and you are done.

Bzzt. Wrong.

As you said, this is all hypothetical. Just as Julian said:
``hypothetical bit stream''.

How did you get ``frame'' involved?

You're mixing high-level, and low-level implementation.

Once you have that bit stream ready and built, as outlined
above by me, _THEN_ you pass it to the upper layers
which will take care of sending and reordering, and what not.

AND IF an implementation can ``see'' that it can optimize
things just because their bit/byte order is such an such,
then so be it, BUT the explanation should be formal enough
and NOT refer to any particular implementation.

-- 
Luben