FW: iSCSI: Flow Control (Resend)

[Robert Snively <rsnively@Brocade.COM>]

-----Original Message-----
From: Robert Snively 
Sent: Thursday, September 21, 2000 11:03 AM
To: 'David Robinson'; ips@ece.cmu.edu
Subject: RE: iSCSI: Flow Control


>  
>  The TCP connection can have either a command or data.  In either
>  case reading a short fixed amount of data can determine if it is
>  one or the other. With a single connection I can only see deadlock
>  occuring if the initiator sends Command1, Command2, then 
>  Data1 on a single
>  command/data connection. With a single connection this seems like
>  a broken initiator as doing the right thing of C1, D1, C2 shouldn't
>  be any more expensive and it is definately safer. Well one other
>  case can occur is if the initiator wants the target to issue an RTT
>  and it interposes another command before the RTT is received, this
>  too seems like a broken things to do as I don't see much 
>  value in doing RTT
>  on a single connection.
>  
>  In the multiple connection asymettric case this isn't an 
>  issue as data
>  is never interleved with commands.
>  
>  So is there a fundamental requirement that the target must handle
>  the case of C1, C2, then D1? It seems easy to just write the iSCSI
>  initiator to never issue such a sequence and if the target gets
>  one return an error when C2 arrives before D1.
>  

David,

This is one of the most valuable capabilities of SCSI and is very
important to high performance behavior.  It is managed quite successfully
in those "ugly" ways that were previously described.  Basically,
a storage device has the option to choose among a large number of
commands so that they will be completed in an optimum order.  This typically
boosts raw performance of disk drives from about 90 IOs/second to well
in excess of 200.  Even greater performance improvements can be achieved
in storage controllers, since they have deeper caching and far more
powerful and reliable data buffering.  I have heard numbers as high as
100,000 IOPs/sec from a single storage controller.  If you can't do this
well in TCP/IP iSCSI, then you do not have a SCSI solution.

The problem is independent of datagram or not.  The same problem will
show up with symmetric or asymmetric multiple connections and will 
typically interact with the sort of out-of-band flow control and
congestion management being proposed for iSCSI in pathological ways.

FWIW, FC is really not a datagram service, but a messaging 
service (Sequence = message) with acknowledgments as required 
at the link level and/or the protocol level.

Bob

>  It again seems like we are trying to impose or solve 
>  datagram problems
>  in a stream world. Does parallel SCSI have this problem?
>  
>  	-David
>