Re: [rddp] Re: iSCSI/iWARP drafts and flow control

[Caitlin Bestler <cait@asomi.com>]

On Thursday, July 31, 2003, at 07:43 PM, Mallikarjun C. wrote:

>
>> No new wire protocol is required.
>
> Please explain to me how credit can be replenished
> in the following example - without new positive flow
> control protocol.
>
> An initiator sends an immediate command in an untagged
> message to the target (and thus consumes one "fringe" credit).
>
> Considerations: a) CmdSN is not unique, can't be acked.
> b) target may discard it, or may process it c) no assumptions
> can be made based on  subsequent command processing.
>
> The other specific iSCSI PDU types that I listed present
> a similar "problem" - for both directions.

There are three cases:

-- If there is no need to send a further untagged message
    then there is no need to reclaim the credit.

-- If there is a later need to send a untagged message
    against the "main" credits, then the reply to that
    command will replenish the credits.

-- Only exception: when sending an untagged message that
    requires the last "fringe credit", or when the "main"
    credits have been exhausted, a flag is set requesting
    an explicit flow control ack. Or a flag in the untagged
    message could request such a flow control ack.

In general, responses to the "main" untagged messages
replenish both "main" and "fringe" credits. This can
be done without complex accounting, something along
the lines of a "leaky bucket" algorithm.

If you somehow exceed the "maximum" number of "fringe"
credits without using "main" credits, you an simply
use some form of "nop" command, or have a special
"fringe" command to replenish "fringe" credits.
But if such a a command is actually needed, it would
mean that the sender is sending more "fringe" methods
than the statistical methods would have allowed for
in any event.

Credits do not have to be run at a "as close to zero"
basis as possible in order to qualify as flow control.

You will probably object to having to send a reverse
message "just" to ack the fringe methods. However,
exactly such a message is being generated now at
by TCP. If you really have a sequence of "fringe"
/ "oneway" messages, you are already generating
a TCP segment to ack them. The only difference
is that iSER would supply some data with that
reverse flow TCP segment.