Re: iSCSI: unsolicited data

["Julian Satran" <Julian_Satran@il.ibm.com>]

Sandeep,

I assume that TCP will not overcomit (this is also a commitment that is easy to predict and small in size).
iSCSI in this case is on the safe ground whatever it commits.

I agree however that the deadlock statement has no place in the draft and I will take it out.

Julo

Sandeep Joshi <sandeepj@research.bell-labs.com> Sent by: owner-ips@ece.cmu.edu 12-03-01 11:14 PM

To:        ips@ece.cmu.edu         cc:                 Subject:        Re: iSCSI: unsolicited data

(Julian's reply did not get cc:ed to the list.)

Comments in text..

Julian Satran wrote:
> 
> Sandeep,
> 
> The requirements for ordering allow us to overcomit (unsolicited data
> conservatively committed may require large buffering space) without fear of
> deadlock.

Ok..but one cant prevent reordering in the network, and things can
get worse for N connections to a session.

Any target which juggles around overcommitted buffers might have to
do either/both of the following, depending on its buffer management 
strategy :
(a) drop packets _within_ the TCP window (or worse, shrink the receive 
    window which RFC 793 doesn't recommend)
(b) drop data PDUs in the iSCSI window

At the very least, we need to expand on the deadlock rationale in the
draft so that it is not the cause of further questions.


> 
> As for the allowance to send data not right after the command I think that
> you stated correctly that matching data to the command will not involve any
> expensive search (at least not on the fast path) as the data must match the
> first outstanding command.
> 
> The reason we did allow the command to be separated is the old "seek
> separation" reason - allow SCSI commands to start executing
> before they reach the state they need data.

Agreed..how about adding this statement to the draft..?

..Though in most cases, packet arrival rates should be much higher than
this setup time (assume network is faster than the fastest SCSI
device).  
I am not sure one may be able to achieve this "pipeline" effect, add
to the fact that this separation is not even recommended (a SHOULD)

Regards,
-Sandeep


> 
> Julo
> 
> 
>                     Sandeep Joshi
>                     <sandeepj@research.bell       To:     ips@ece.cmu.edu
>                     -labs.com>                    cc:
>                     Sent by:                      Subject:     Re: iSCSI: unsolicited data
>                     owner-ips@ece.cmu.edu
> 
> 
>                     12/01/2001 01:36 AM
> 
> 
> 
> Julian,
> 
> Perhaps this thread was missed..could you please elaborate on this
> deadlock issue..when exactly does it occur?
> Note that I am not asking for out-of-order data!
> 
> There was one more question - regarding the allowance given
> to the initiator to *not* send unsolicited PDUs right after
> the command PDUs, which raises persistent questions.
> 
> See http://www.pdl.cmu.edu/mailinglists/ips/mail/msg07930.html
> for the latest question on this issue.
> 
> IIRC, the reasoning here was that this helps the target in "positioning"
> operations - since it gets a few commands first, and then the data.
> By positioning, do you imply disk/tape seeks or something else ?
> Note that the draft must atleast mention the above rationale if we
> wish initiators to behave as such, and also targets to optimize for it.
> 
> Regards,
> -Sandeep
> 
> "Mallikarjun C." wrote:
> > I however could not really see a deadlock per se - my comment was to
> > understand
> > what it is.    More comments would certainly help.
> >
> > ----- Original Message -----
> > From: "Julian Satran" <Julian_Satran@il.ibm.com>
> > > Mallikarjun,
> > >
> > > The deadlock free requirement here goes a bit deeper than your comment
> may
> > > suggest.
> > > Unsolicited data needs are very hard to predict and ordering them may
> > > remove the need to do so to a large extent.