RE: Immediate Commands in iSCSI

[Black_David@xxxxxxx]

Crucial editing mistake - see below.  Sorry, --David

> Jijo,
> 
> > 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.
> 
> Happy to do so, as that last statement is incorrect, because
> the initial assumption is wrong.  Tagged command queuing is in
> SAM-2, which is normatively referenced by iSCSI (RFC 3720).  The
> mechanism that you're looking for is TASK SET FULL status (28h),
> which is widely supported.  The recent discussion on this list
> was specific to iSCSI commands, which are intended for exceptional

"iSCSI commands" --> "immediate iSCSI commands"

> cases where the outstanding queue of undelivered commands
> in iSCSI needs to be bypassed (see Section 3.2.2.1 of RFC 3720).
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david@xxxxxxx        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 


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