RE: iSCSI: Flow Control

[Michael Krause <krause@cup.hp.com>]

At 07:44 PM 10/4/00 -0700, Jim McGrath wrote:


>Why use an indirect means instead of a direct means?
>
>The problem here is that a single command can overwhelm my resources, since
>it can consume a near infinite amount of buffer space.  This is similar
>(although a bit better) to the situation in FC-AL, where the login credit
>the target gave an initiator could apply to any one of the possible 256
>queuable commands.  So to provide a 2 credit (4 Kbyte) immediate data window
>to an initiator at login I had to reserve 1 MB of buffer space.
>
>I may want to let you send me a lot of commands (for scheduling purposes),
>but not get the data for them yet.  The two issues (command flow and data
>flow) are really very separable.
>
>I think people can live with the allocation of resources for commands and
>the allocation of resources for data.  But allocating one without addressing
>the other is not a solution to the problem of immediate commands and data
>people have been raising.

It really comes down to advertising a byte window which can be sliced into 
commands and data.  The credits and operations being tracked do not require 
complex implementations to track or exchange.  Why can't one use / leverage 
the same sliding window type of buffer advertisement that TCP uses and the 
sender who is initiating the command will know whether it can send the 
command with immediate data or must resort to a command with the remote 
fetching the data?

Mike