Re: Immediate Commands in iSCSI

[email protected] Thu, 6 Dec 2007 10:23:38 -0500
Newsgroups gmane.ietf.ips
Message-ID <OF4F9E66C7.4731027B-ON852573A9.005478C0-852573A9.0054900A@attotech.com>
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" <[email protected]> 
12/06/2007 04:12 AM

To
"Ken Sandars" <[email protected]>
cc
[email protected], [email protected], [email protected], 
[email protected]
Subject
Re: [Ips] 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
[email protected]
https://www1.ietf.org/mailman/listinfo/ips 

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

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