Re: Immediate Commands in iSCSI

[dcuddihy@xxxxxxxxxxxx]

Jijo,

There is an ISCSI level flow control
from the target back to the initiator via the MaxCmdSn field.  The
field can be found in the SCSI response, and it stops initiators from sending
more than (MaxCmdSn-ExpCmdSn+1) commands on the session at any one time.
 See RFC 3720 10.4 (specifically 10.4.11) for more information.

regards,

david


Java: The elegant simplicity of C++ 
and the blazing speed of smalltalk.

David J Cuddihy
Principal Engineer
ATTO Technology, Inc.

www.attotech.com
Power Behind the Storage

"Jijo Chacko" <consultant.bangalore@xxxxxxxxx>

12/06/2007 04:12 AM

To	"Ken Sandars" <kensandars@xxxxxxxxxxx>
cc	ips@xxxxxxxx, jacob_cherian@xxxxxxxx, nam_nguyen@xxxxxxxx, julian_satran@xxxxxxxxxx
Subject	Re: Immediate Commands in iSCSI

A related question - from the above discussions, i assume that there is
no, application-level, end-to-end flow control from the initiator-to-target,
as it relates to queued commands. As TCP flow control layers already allowed
the command-bytes in to the host,  we have the memory buffers at the
TCP layer, and later commands are just ignored, with ICR return code 0x06.
And initiator re-submits, target re-rejects,  and this repeats this
is not good for internet, as it relates to congestion. When tagged queueing/no
of outstanding commands support added to SCSI, iSCSI was not in anybody's
mind(IMHO).. please dis-agree with me here. 

And strongly feel that, we need to have some way of throttling the initiator
to prevent from swamping the target, or  target implementation code
should have the logic to re-submit the un-honored commands from the TCP
buffers(or local buffers), before returning an error code to the initiator.
or there can be an iSCSI, pending-coomands cache at the target stack, to
solve this problem. 

In essence, IMHO, we should do some fixes for target iSCSI implementation,
to provide some staging buffers for already tcp-received commands. We should
not be returning wrong error code to the initiator, if we already received
the command at the TCP layer, and the target has the ability to apply it.
We should be returning the error code only if target failed to apply it.

IN the SCSI world, as the number of initiators are typically just 1, and
the data is not travelling across WAN, target can  return "Too
many commands pending" errors.. as it has only local effect, having
few meters. 

Please correct me, if i am wrong... 

thanks,
Jijo Chacko
Bangalore.

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

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

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