Re: Immediate Commands in iSCSI

[William Stouder-Studenmund <wrstuden@xxxxxxx>]

On Dec 2, 2007, at 7:20 PM, Jacob_Cherian@xxxxxxxx wrote:

> RFC 3720 states:
> The number of commands used for immediate delivery is not limited  
> and their delivery for execution is not acknowledged through the  
> numbering scheme. Immediate commands MAY be rejected by the iSCSI  
> target layer due to a lack of resources. An iSCSI target MUST be  
> able to handle at least one immediate task management command and  
> one immediate non-task-management iSCSI command per connection at  
> any time.
>
> With storage systems that have very large number of logical units,  
> we run into an issue when we use LU Reset or Abort Task for reset  
> recovery. I couldn’t find a way to tell an initiator how many  
> immediate commands a target can accept. The issue with this is that  
> if we have to issue multiple task management commands and it is more  
> than what the target can accept, it will reject the task management  
> request. Since we don’t know why it was rejected, we will have to  
> escalate the reset. This can be very disruptive with nodes that have  
> very large number of logical units. There may be two ways to resolve  
> this:
>
> 1)      Define a new Text negotiation key for number of outstanding  
> immediate commands supported. Unlike non-immediate (data) commands  
> where we can send TASK SET FULL, there is no way for a target to  
> report in the Task Management Function Response PDU that is unable  
> to process the current request before it is out of resources.  The  
> default vaule for this new key can be 1, so if this key is not  
> negotiated initiators can assume one per connection.

If we were to add this key, I think there should be no default. No  
negotiation result should leave both parties with the current "try it  
and see what happens" behavior.

> 2)      Define a new value for the Response field in the Task  
> Management Function Response PDU for reporting that the target  
> cannot process the request currently.
>
> Any suggestions on how to resolve this?

Since we're talking about changing the protocol, why not just fix the  
problem? The problem is a lack of clarity about why an operation  
failed, so let's add an extra response code to indicate a transient  
issue. Something to the effect of, "I'm rejecting/failing this, but I  
think the reasons was transient and may not hold true if you try the  
command again."

I'm not sure if anything other than TMR needs this treatment.

Take care,

Bill

_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips