Subject: Re: iSCSI: Checking the I bit

From: "John Hufferd" <[email-masked]>
Date: Fri, 14 Dec 2001 16:16:45 -0800

OK,
Except for the fact that Eddy pointed out to me 3.2.1.1 does call it the I
bit that is always set to 1 for responses (and Async Msgs by the way),  I
think my basic statement is still true -- It is not a reserved bit.   So
the UNH statements really does not apply.  And if it is a bit that is
always set to one but does not need to be checked, why is it set to one?
Why not set it to zero and mark it reserved, so that the UNH statement does
apply, and then we can use it for something else in the future.  The bit
seems redundant, why do we need it to be set?

Does this have something to do about with expediting the handling of
responses in a target which is working on extended copy commands?

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

Julian Satran/Haifa/IBM@[email-masked] on 12/14/2001 09:15:29 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: iSCSI: Checking the I bit

I think that Eddy's suggestion to state that parties have to check only
what they have to check is valuable and we may want to include a general
statement about that.

Julo

                     John Hufferd                                        
                     Sent by:                  To:                       
                     [email-masked]   "Eddy                             
                     mu.edu            Quicksall"                        
                                       <Eddy@Quicksall                   
                     14-12-01 09:55    .com>                             
                                               cc:                       
                                       "ips@ece. cmu.                    
                                       edu \(E-mail\)"                   
                                       <[email-masked]                   
                                       u>                                
                                                                         
                                       Subject:                          
                                       Re: iSCSI:                        
                                       Checking the I                    
                                       bit                               

Eddy,
Technically, the In coming PDUs all have Byte 0, Bit 6, set to one.  It is
not identified as the I (Immediate) bit.  And it is NOT reserved.

So the Statement from the UNH Plugfest does not apply.  I think your point
is that if all the incoming PDUs have that bit set, why do we need to set
the bit, and why do we need to check it.  I think this bit has evolved over
time, and perhaps up to now no one has noticed.

If every incoming PDU has the bit set, we may not need the bit to be set,
and perhaps it should be reserved, thereby not requiring the check.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

"Eddy Quicksall" <[email-masked]>@ece.cmu.edu on 12/13/2001 03:26:18 AM

Sent by:  [email-masked]

To:   "ips@ece. cmu. edu \(E-mail\)" <[email-masked]>
cc:
Subject:  iSCSI: Checking the I bit

Is it necessary for  the initiator to check the I bit in every response?

If an initiator does  not need it, then I don't want to take the extra time
to check it. I think this  is consistent with the thinking of all attendees
of the UNH Plug Fest because  the report from UNH IOL was that "all
companies failed that  test".

I would like to  propose adding some wording to 3.2.1.1 similar to "It is
not necessary to check  this bit for 1 if the implementation in the
initiator does not need its  use".

[email-masked]

---

From: "Eddy Quicksall" <[email-masked]>
Date: Tue, 18 Dec 2001 09:30:34 -0500

This has become three issues:

1) The issue of a device checking to see if the other device is compliant
(the "reserved I bit" happens to fall into this category).
2) The issue of a "1" bit being called a reserved bit
3) The issue of forcing the "I" bit to be 1 for all responses

What I am most interested in is issue 1. Because that can be an unnecessary
performance hit (if there are too many things to check) and a nuisance. This
should be an implementation issue.

For issue 2, I now have mixed emotions. You guys have read many more
documents than I have. But I have always assumed that reserved fields are
set to 0. If it needs to be a 1, why not just say that?

For issue 3, I also wonder why it needs to be a 1. We should probably
explain that in the spec so the need is not lost.

Eddy

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Friday, December 14, 2001 7:17 PM
To: Julian Satran
Cc: [email-masked]
Subject: Re: iSCSI: Checking the I bit

OK,
Except for the fact that Eddy pointed out to me 3.2.1.1 does call it the
I
bit that is always set to 1 for responses (and Async Msgs by the way),
I
think my basic statement is still true -- It is not a reserved bit.   So
the UNH statements really does not apply.  And if it is a bit that is
always set to one but does not need to be checked, why is it set to one?
Why not set it to zero and mark it reserved, so that the UNH statement
does
apply, and then we can use it for something else in the future.  The bit
seems redundant, why do we need it to be set?

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

Julo

                     John Hufferd

                     Sent by:                  To:

                     [email-masked]   "Eddy

                     mu.edu            Quicksall"

                                       <Eddy@Quicksall

                     14-12-01 09:55    .com>

                                               cc:

                                       "ips@ece. cmu.

                                       edu \(E-mail\)"

                                       <[email-masked]

                                       u>

                                       Subject:

                                       Re: iSCSI:

                                       Checking the I

                                       bit

Eddy,
Technically, the In coming PDUs all have Byte 0, Bit 6, set to one.  It
is
not identified as the I (Immediate) bit.  And it is NOT reserved.

So the Statement from the UNH Plugfest does not apply.  I think your
point
is that if all the incoming PDUs have that bit set, why do we need to
set
the bit, and why do we need to check it.  I think this bit has evolved
over
time, and perhaps up to now no one has noticed.

If every incoming PDU has the bit set, we may not need the bit to be
set,
and perhaps it should be reserved, thereby not requiring the check.

.
.
.
John L. Hufferd

"Eddy Quicksall" <[email-masked]>@ece.cmu.edu on 12/13/2001 03:26:18
AM

If an initiator does  not need it, then I don't want to take the extra
time
to check it. I think this  is consistent with the thinking of all
attendees
of the UNH Plug Fest because  the report from UNH IOL was that "all
companies failed that  test".

I would like to  propose adding some wording to 3.2.1.1 similar to "It
is
not necessary to check  this bit for 1 if the implementation in the
initiator does not need its  use".

---

From: Paul Koning <[email-masked]>
Date: Tue, 18 Dec 2001 15:22:08 -0500 (EST)

>>>>> "Eddy" == Eddy Quicksall <[email-masked]> writes:

 Eddy> This has become three issues: 1) The issue of a device checking
 Eddy> to see if the other device is compliant (the "reserved I bit"
 Eddy> happens to fall into this category).  2) The issue of a "1" bit
 Eddy> being called a reserved bit 3) The issue of forcing the "I" bit
 Eddy> to be 1 for all responses

 Eddy> What I am most interested in is issue 1. Because that can be an
 Eddy> unnecessary performance hit (if there are too many things to
 Eddy> check) and a nuisance. This should be an implementation issue.

We had a discussion about this a few weeks ago on the list.  I believe
the outcome was that checking reserved bits is, minimally, not needed,
and in fact either disallowed entirely or at the very least
discouraged.  (I.e., it is either "MUST NOT check" or "SHOULD NOT
check".) 

	 paul