RE: iSCSI: Flow Control

["Douglas Otis" <dotis@sanlight.net>]

Pierre,
<snip>
> Doug,
>
> WRTCMD-DATA is it a write with immediate data?
>
> In this case, whatever you do you, the next command/task
> management request
> needs to wait the time the PDU (command+immediate data) is transmit on
> the wire. If an application wants immediate data, it will have some added
> latency for the other commands. It's up to the application to
> find the right trade-off between write data transmit latency and
> command transmit latency.
> Buffer management can't do nothing for that.

If the network is a 125 mile MAN, then you will see 1 millisecond latency on
the network.  The 17 microsecond per frame at 1G-bit means there are 60
frames in flight.  That would also mean there are about 120 frames
unacknowledged at any point in time.  Should the transmit buffer grow to a
frame value much greater than this, it will be adding latency to the system
and thus not improving performance for critical a frame.

<snip>

> Humm, if you want something as TCP windowing you  need a big
> window if you have
>
> a large latency in the network to avoid underun the target. May be
> you think about a solution with SCTP (i am not familiar with it),
> one stream
> for data and one stream for command inside a same connection?
> Anyway with one TCP connection, you can't do that. If you use
> one TCP connexion for command and one for data with comes back
> to the synchronization problems.

SCTP does not offer the feature you describe. Once data is delivered to the
transport layer, the application looses ability to organize delivery.  As it
is easy to out pace the network, should critical command performance be
considered, then the application must considered some means to prevent
over-extending transmit buffers.

> > > However, the main market will be using adapters
> > > "a la" SCSI, no?
> >
> > No. If you require separate network connections to a client,
> then you have
> > substantially reduced the benefit of making the SAN common to IP.  FC
> > already works well and would make a better choice if two
> adapters would be
> > required.
>
> You are right, it is an advantage to have only one card for the network
> traffic. This doesn't  means that that card can't have too a
> "transaction" interface "a la" FC.

If you do not want to use known operations of TCP, then why use TCP?  If you
wish to re-invent the API, stack, and structures within TCP, then why use
TCP?  It would be easier to declare a new protocol than to mix a bastardized
version together with a standard version.  If you wish to simulate FC, then
SCTP would allow simulation without making a bastardized protocol.  To bury
the protocol within the adapter as you suggest, then you will require the
benefits offered by SCTP.

Doug

>
> Regards,
>
> Pierre
>