Re: iSCSI/iWARP drafts and flow control

[Caitlin Bestler <cait@asomi.com>]

On Thursday, August 7, 2003, at 12:52 PM, Mike Ko wrote:

> Caitlin, since MaxCmdSN is used by the target to limit the number of
> commands it can receive from the initiator, your suggestion would work 
> for
> limiting the number of "fringe" messages the initiator can send to the
> target.  However, for "fringe" messages from the target to the 
> initiator,
> such as the Aysnchronous Message, the target cannot simply raise 
> MaxCmdSN
> and expect the initiator to increase the number of receive buffers for
> "fringe" messages correspondingly.
>
> Mallikarjun is correct in pointing out that some form of new wire 
> protocol
> for flow control is required if we need to flow control the messages 
> not
> regulated by CmdSN.

To be more precise, no general purpose wire protocol is required
that must act as a filter on every untagged message. The procedure
I outlined deals with "fringe" messages from the initiator. It is
logic that is never needed more often than per-fringe-message, and
generally requires no additional messages.

If fail to see why that cannot be worked out for each category
of message that iSCSI requires. All that is required is to identify
some acknowledgment that flows in the desired direction. Under the
worst case you might be forced to create a message for the sole
purpose of restoring credits.

You cannot claim that SCSI functionality over RDMA is incompatible
with flow control. SCSI over TCP/IP is flow controlled by TCP,
iSER flow control would be *less* restrictive than TCP flow control,
but it does have to be identified and specified. Additionally
SRP is fully defined to work over RDMA with flow control. The
problem has a solution. There is no justification for exempting
iSER from the responsibility to provide ULP flow control.