RE: iSCSI: Flow Control

["Binford, Charles" <cbinford@lsil.com>]

Title: RE: iSCSI: Flow Control

Just to clarify things.  FCP-2 did not forbid immediate data.  Bob Snively's recent posting as to what was removed in FCP-2 was the combining of command and data IN THE SAME SEQUENCE.  This is an FC specific issue and does not apply to iSCSI.

FCP-2 still has the concept of initial Write XFER_RDY disable.  This allows up to burst size (set in a Mode page) amount of data to be sent immediately after the command (but in a different FC sequence).

That said, I am not aware of anyone who actually supports this option.  If iSCSI decides this is a good thing, then I believe the command queue depth management schemes built into SCSI are not sufficient.  Bob Snively has recently spelled out how those work in another posting.  I agree they work in an environment where immediate data is not allowed.  Retransmitting a short CDB pdu/frame is not a big deal.  However, if data was sent and it has to be retransmitted in addition to the CDB, then it suddenly becomes an issue.

Also, I believe the current command queue depth handling works acceptably well because most current SCSI implementations (i.e. parallel, fc, 1394, etc.) all have very short transport latency times.  If we're talking about retransmitting a "queue-fulled" CDB cross country, then I think we need to consider a method that governs the queue depth and not assume the current SCSI mechanism will work in this environment.

Charles Binford
LSI Logic Storage Systems
(316) 636-8566

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Friday, September 29, 2000 3:39 PM
> To: julian_satran@il.ibm.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: Flow Control
>
>
> > Sorry for not being more explicit. The window can close as
> C2+D2 (but
> > mainly D2) are not consumed as they are processed after C1.
> >
> > The scenario holds and the blocking results from a "order
> reversal" of the
> data in the stream
> > caused by enabling both immediate data and R2T.
>
> In which case, this target should forbid immediate data if its buffer
> resources
> are that slim; I think we're in violent agreement on that.
>
> Putting my WG co-chair hat back on:
>
> The open question to the list is whether there's value in allowing
> some amount of immediate data (e.g., for targets that need
> fast startup on
> long latency connections, and are prepared to deploy the
> buffering required
> to make it work reliably), or whether we ought to follow
> FCP-2 and forbid
> immediate data, which will impose a round trip delay (command out, R2T
> back) before data starts to flow.  I think I've seen a couple
> of comments
> in favor of this, but more discussion is in order.
>
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
>