Subject: RE: iSCSI: Use of the A bit

From: "John Hufferd" <[email-masked]>
Date: Wed, 13 Mar 2002 18:55:46 -0800

I like this response.  I think it is correct and the best response so far
on this topic.

Does anyone disagree with this?

.
.
.
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]

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
@ece.cmu.edu on 03/13/2002 10:39:27 AM

Sent by:    [email-masked]

To:    "'Eddy Quicksall'" <[email-masked]>, "ips@ece. cmu. edu
       (E-mail)" <[email-masked]>
cc:
Subject:    RE: iSCSI: Use of the A bit

Eddy,

The target is quite within its rights to use the A bit  when at recovery
level 0.  If the session is re-established due to recovery  7.11.4 then the
relevant command is aborted anyway and so there is no reason to  keep hold
of the data any way: With recovery level 0 there is no recovery  mechanism
that requires the target to keep the data.  Therefore the A bit  is
redundant when the recovery level is 0.

The spec says that the initiator MUST issue a SNACK if  the A bit is set.
However, the MaxBurstSize restriction is there to  prevent the initiator
from having to send a SNACK on every PDU in the case where  a target
inadvertently sets the A bit in (for example) every data in  PDU. The
target may set the A bit more often than the MaxBurstSize but it  should
not expect a SNACK more often than this.

Matthew Burbridge
-----Original Message-----
From: Eddy Quicksall  [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002  3:12 PM
To: ips@ece. cmu. edu (E-mail)
Subject: iSCSI: Use  of the A bit

Here is a case  that I want to go over and if there is not already a
solution, I think a  refinement to the A bit could solve it.

The problem is  that a target (perhaps an iSCSI disk drive) does not have
enough memory to  transfer the full READ request so it must read from the
medium as much as  it can, transmit that, when that transmission is known
to be good, read the  next bunch, transmit that and so on.

The problem we  have is that the target must keep the buffer around until
the transfer has  been "ack'd" via ExpStatSN. But that status can't be sent
because all of the  requested data has not been sent. So the target would
have to refuse to do the  command.

I was going to use  the A bit for this thinking it would force the
initiator to give an "ack" but  our current wording does not make this a
sure fire thing:

1) The initiator  may not want to run at ErrorRecoveryLevel 1.
2) The initiator  may ignore the A bit if it deems that the bit is being
set  aggressively.
3) The target may  set the A bit no more frequently than MaxBurstSize.

Comments?

mailto:[email-masked]

---

From: Paul Koning <[email-masked]>
Date: Thu, 14 Mar 2002 09:22:12 -0500

>>>>> "John" == John Hufferd <[email-masked]> writes:

 John> I like this response.  I think it is correct and the best
 John> response so far on this topic.

I think it's essentially correct, see below.  I agree with the
conclusion. 

 >> "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
 >> <[email-masked]> @ece.cmu.edu on 03/13/2002 10:39:27
 >> AM

 >> The target is quite within its rights to use the A bit when at
 >> recovery level 0.  If the session is re-established due to
 >> recovery 7.11.4 then the relevant command is aborted anyway and
 >> so there is no reason to keep hold of the data any way: With
 >> recovery level 0 there is no recovery mechanism that requires
 >> the target to keep the data.  Therefore the A bit is redundant
 >> when the recovery level is 0.

 >> The spec says that the initiator MUST issue a SNACK if the A
 >> bit is set.  However, the MaxBurstSize restriction is there to
 >> prevent the initiator from having to send a SNACK on every PDU
 >> in the case where a target inadvertently sets the A bit in (for
 >> example) every data in PDU. The target may set the A bit more
 >> often than the MaxBurstSize but it should not expect a SNACK
 >> more often than this.

The spec says that the target MUST NOT set the A it more often that
MaxBurstSize.  If it does, that would be a protocol violation.  Is is
perfectly reasonable for the initiator to ignore A bits that are
protocol violations; even if the spec had not stated so explicitly,
that would have been true.

     paul