RE: iSCSI: Flow Control

[Joshua Tseng/Nishan Systems <joshua.tseng@NishanSystems.com>]

Mike,

>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?
>

There is an issue I'd like to bring up with using TCP to flow control
the commands.  I don't know how serious it is, but I would like to
point this issue out for anyone knowledgeable to comment.

As was discussed earlier, TCP may need to buffer 16MB or more of
data in order to work at gigabit speeds and 100+ms of latency.  With
this much data being buffered in the initiator's transmit buffer,
how does this affect the initiator's ability to send task management
functions?  I understand most task management functions involve
reset or reboot type of operations, but can these messages afford
to wait behind a large queue of data in the TCP buffer?

The alternative would be a credit-based command flow control mechanism,
allowing the initiator to put a TMF at the head of the queue of data
to be transmitted to the target.

Josh