Re: iSCSI ACA - Implementers Guide (long, sorry)

On Feb 1, 2006, at 2:22 PM, [email protected] wrote:

> Consolidating responses to Eddy and Bill.  The most important piece
> of this message is the last paragraph (repeated here):
>
>   ACA and multi-connection iSCSI sessions are a lousy fit.  Would
>   it be worth saying that ACA SHOULD NOT be used on multi-connection
>   iSCSI sessions and initiators are responsible for dealing with
>   the response ordering issues that arise when ACA is used on
>   a multi-connection session?  That would be mostly consistent
>   with RFC 3720 and impose no ACA implementation burden on
>   targets.
>
> Please comment.

I like it. It means I don't have to do anything extreme. :-)

> --- William Studenmund wrote:
>
>>> -- (1) The SCSI response indicating that CHECK CONDITION has
>>> 	caused establishment of ACA could get ahead of a response
>>> 	to a command completed prior to establishment of ACA.
>
>> Well, the first question that comes to my mind in these cases is what
>> does Fibre Channel do in these cases on a large SAN? Or what is FC
>> doing on SANs that are bridged over IP? :-)
>>
>> We shouldn't beat ourselves up to do stuff the FC doesn't. :-)
>
> Fibre Channel doesn't have multi-connection sessions, and hence these
> ACA-related reordering-across-connections problems don't arise.

Ok.

>> I was going to suggest a bit of a tangent here by suggesting we  
>> pull in
>> a post-SAM-2 feature and add support for the Query Task Task  
>> Management
>> Function. However I think that that function only indicates if a task
>> is in the task set or not. Hmmm... Maybe that is enough.
>
> That's a separable item.  At some point, someone will write the  
> draft to
> update iSCSI to SAM-3 (backwards compatible - any incompatible  
> behavior
> differences have to be negotiated), and QUERY TASK would be part of  
> that.

Sounds good.

>> I really have all of these delays we are building into the target. If
>> we are in a MC/S situation, shouldn't we expect the initiator
>> to carry some of the load?
>>
>> Put another way, if the initiator can't handle ACA cleanup, maybe it
>> shouldn't issue commands with NACA set. :-)
>
> The issue here is that multi-connection iSCSI sessions without
> target synchronization of responses add out-of-order response cases
> for ACA that a SCSI initiator isn't expecting.  RFC 3720 says ACA
> is entirely a SCSI-layer issue.

Ahh... I was a bit sloppy. A better way to say this may be that an  
iSCSI initiator shouldn't accept CDBs with NACA set if it can't  
handle cleanup. :-)

So should the (iSCSI) initiator complain if commands are issued with  
NACA set and we're in MC/S?

>> The problem is that there is no way to indicate target status across
>> the whole session; status is a per-connection thing (which is usually
>> great!).
>>
>> The only other thing I can think of is to add a new async event
>> indicating we entered ACA and that all status messages with StatSN  
>> less
>> than this one were completed before the event.
>
> And issue that on every connection in the session for ACA?  IMHO, it's
> probably better to wait for the status acks, issuing NOPs as needed to
> get them (as Eddy notes above).

Yes, on every connection. My thought was that the special event would  
have the advantage that it immediately flags that something is going  
on. Also, once we get this event on all connections, we know we're  
done (modulo Status SNACKing).

But just not using ACA in MC/S is easier. :-)

>>> -- (2) An ACA ACTIVE status response could get ahead of the SCSI
>>> 	response that indicates establishment of ACA.
>
>> Is this issue really a special worry?
>>
>> As I understand SAM-2, this can always happen. In table 25, if  
>> QErr is
>> 00b and TST is 000b, some OTHER initiator triggering ACA can put our
>> port into ACA ("all enabled tasks from all SCSI initiator ports"). So
>> there may not even be a status event with the CHECK CONDITION on  
>> any of
>> our connections. Thus we can suddenly find ourselves in ACA. :-|
>
> Right, but what if they're not?  Also, an initiator who reacts to this
> situation by retrying the task (on the assumption that the other  
> initiator
> will get out of ACA eventually) is in for a surprise when the ACA  
> turns
> out to be its own fault.  I would hope the common case for ACA is  
> single
> initiator devices or TST = 001b (task set per initiator), but I  
> don't know.

I agree it really only makes sense in a single-initiator device  
(well, usage). At least as I understand why you want ACA, which was  
to be able to make tape command streams work right in face of EOT  
events.

>>> Between (1) and (2) it's probably a good idea to advise
>>> initiator implementers that the synchronous nature of ACA
>>> makes it a poor fit with the concurrency of multi-connection
>>> iSCSI sessions.
>>
>> Indeed. Consider the further wrinkle of a slow initiator (or slow
>> connections) in a QErr 00b/TST 000b scenario. Another initiator could
>> have cleared ACA and RETRIGGERED ACA before the one initiator could
>> have cleared it. :-)
>
> Again, I think ACA and TST = 000b (single task set for all initiators)
> are a lousy match for multi-initiator devices.  That would also be
> worth saying in the implementers guide.

Ok. Agreed.

>>> Comments? (and sorry for the length)
>>
>> I think this is a mess. For ACA to work well, it really needs the  
>> SCSI
>> world to be different than it is normally for iSCSI. :-(
>
> I think it's slightly more specific as noted above - ACA and
> multi-connection iSCSI sessions are a lousy fit.  Would it be
> worth saying that ACA SHOULD NOT be used on multi-connection
> iSCSI sessions and initiators are responsible for dealing with
> the response ordering issues that arise when ACA is used on
> a multi-connection session?  That would be mostly consistent
> with RFC 3720 and impose no ACA implementation burden on
> targets.

As I make targets, I really like this idea. :-)

Take care,

Bill

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips