RE: Immediate Commands in iSCSI

Jacob,

I do not want to appear offensive - but did you consider the "larger 
picture"? Assuming that the negotiation key or status is there and 
assuming that the target talks to 7 (seven) different initiators what 
would it tell each of them (it has 7 different sessions)? Should he 
reserve a quota for each of them - so that it can meet what it declared? 
What should a target do with commands that exceed the number? 

In iSCSI as a rule we avoided setting or negotiating parameters that we 
don't need to set/negotiate and I think the number of accepted immediate 
commands is one of them.

Julo





RE: [Ips] Immediate Commands in iSCSI

Jacob_Cherian 
to:
Julian Satran
12/03/07 04:06 PM


Cc:
ips, Nam_Nguyen







The goal of the new status or key is to help the initiator to know the 
correct number of immediate commands that the target supports. The issue 
with overloading a status that does clearly define the error condition is 
that it does help in achieving interoperability between the myriad of 
initiators and targets that are out there. I was looking to see if there 
was another way that I had not considered.
 
Jacob
 
 
From: Julian Satran [mailto:[email protected]] 
Sent: Monday, December 03, 2007 1:23 AM
To: Cherian, Jacob
Cc: [email protected]; Nguyen, Nam
Subject: Re: [Ips] Immediate Commands in iSCSI
 

It looks to  me that the Reject response with reason 0x06 should be enough 
for the initiator to handle the situation you describe. 
If the TM are the cause then each of those has a response indicating 
termination. After receiving a reject an initiator should reissue new TMs 
only after getting back one or more responses.  The initiator may even 
accurately guess the number of commands the targets is capable of handling 
per connection and per LU. The only case in which this handling may be 
awkward is over a WAN but if you are operating over a WAN and TM 
performance is your only worry you are in good shape :-) 

Julo 





[Ips] Immediate Commands in iSCSI
 


Jacob_Cherian 
to: 
ips 
12/03/07 05:23 AM
 



Cc: 
Nam_Nguyen



 





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. 

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? 

  

Thanks, 

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

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