Subject: RE: iSCSI: unsolicited data

From: "Somesh Gupta" <[email-masked]>
Date: Sun, 2 Dec 2001 14:52:30 -0800

Sandeep,

As discussed earlier, the implementation complexity, especially
in network processor like devices is very different between the
two cases - data in the same order as the commands, and not in
the same order is very different. It is best if as you suggest,
data follows the PDU. In any case, the condition of having the
data follow in the same order as the commands should not be
relaxed at all. Only in the presence of an actual digest error
should this condition be not considered a severe protocol error.

Somesh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Sandeep Joshi
> Sent: Friday, November 30, 2001 3:36 PM
> To: [email-masked]
> Subject: Re: iSCSI: unsolicited data
> 
> 
> 
> 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" <[email-masked]>
> > > 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.
>

---

From: Sandeep Joshi <[email-masked]>
Date: Mon, 03 Dec 2001 16:14:33 -0500

(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
>                     <[email-masked]       To:     [email-masked]
>                     -labs.com>                    cc:
>                     Sent by:                      Subject:     Re: iSCSI: unsolicited data
>                     [email-masked]
> 
> 
>                     12/01/2001 01:36 AM
> 
> 
> 
> Julian,
> 
> > > The deadlock free requirement here goes a bit deeper than your comment
> may
> > > suggest.