Julian,
No offense taken. The scenario that you
brought up was considered since most configurations with iSCSI are with
multiple hosts. However, the allocation of immediate commands to connection/sessions/hosts
depends on the actual implementation. RFC 3720 already requires support for at
least one per connection. Even we cannot agree on a key, having a more granular
status for a rejected TMF that says the target is currently busy processing a
TMF and cannot process another at this time (but will be able to sometime in
the future), helps initiators to wait and retry, instead of assuming a failure
and escalating the reset.
Jacob
From: Julian Satran
[mailto:Julian_Satran@xxxxxxxxxx]
Sent: Monday, December 03, 2007 8:42 AM
To: Cherian, Jacob
Cc: ips@xxxxxxxx; Nguyen, Nam
Subject: 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
|
|
|
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:Julian_Satran@xxxxxxxxxx]
Sent: Monday, December 03, 2007 1:23 AM
To: Cherian, Jacob
Cc: ips@xxxxxxxx; Nguyen, Nam
Subject: Re: 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
|
|
|
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
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips
