RE: RE: Re: multiple connections

[somesh_gupta@hp.com]

> -----Original Message-----
> From: rsnively@Brocade.COM [mailto:rsnively@Brocade.COM]
> Sent: Thursday, September 07, 2000 9:33 AM
> To: somesh_gupta@hp.com; ips@ece.cmu.edu; matt_wakeley@agilent.com
> Subject: FW: RE: Re: multiple connections
> 
> 
> 
> 
> >  -----Original Message-----
> >  From: somesh_gupta@hp.com [mailto:somesh_gupta@hp.com]
> >  Sent: Wednesday, September 06, 2000 5:12 PM
> >  To: ips@ece.cmu.edu; matt_wakeley@agilent.com
> >  Subject: RE: Re: multiple connections
> >  
>      snip
> >  
> >  2. WRITES - This is the really bad one in my opinion. For 
> >  me, avoiding
> >  RTTs in iSCSI would just by itself make iSCSI a superior 
> "transport"
> >  for SCSI. So assuming RTTs are not being used, the host 
> >  would (changing
> >  the posting order from READs), first post the write command to the
> >  connection on which the data is to be sent, and then post the write
> >  buffers to the connection which is to be used for sending data.
> >  One case is where for whatever reason, the target gets the 
> >  data before
> >  it gets the command, and has no clue what to do with the data.
> >  Let us assume that the target does get the command before 
> it gets the
> >  data. The target gets a command indicating that data being 
> >  written to 
> >  whatever lun and whatever location is going to arrive on some other
> >  connection. First the target has taken an extra event from 
> >  the adapter.
> >  Then, when data arrives on another NIC (and the target gets another
> >  event), the target goes through the list of outstanding WRITE
> >  commands to match the command with the data and then go about the
> >  business of processing the data.
> >  
> >  So in this case the work has increased for the initiator as well as
> >  the target.
> 
> 
> And to top it off, the target is active with a large number of
> initiators on behalf of a large number of logical units for a large
> number of queued commands, so there is absolutely no guarantee that
> any buffer exists for the data that was received, even if the
> command had been received first.
> 
> Every SCSI command execution is managed by the target for 
> this reason among
> many others.  Thus RTT has been a part of every SCSI protocol 
> for write
> operations.
> 

TCP window size should provide a reasonable flow control mechanism,
so an additional flow control should not be needed. There will be
some statistical determination of the amount of memory needed in
a large array vs the window size extended on each connection.

I don't know if arrays like to keep commands in seperate memory
from data, in which case a command queue depth may have to be 
communicated seperately (assuming most of window would typically
be used for data)