Subject: Re: iSCSI: unsolicited data

From: "Julian Satran" <[email-masked]>
Date: Tue, 4 Dec 2001 12:40:36 +0200

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 <[email-masked]>
Sent by: [email-masked]
12-03-01 11:14 PM

        To:     [email-masked]
        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
>                     <[email-masked]       To: [email-masked]
>                     -labs.com>                    cc:
>                     Sent by:                      Subject:     Re: 
iSCSI: unsolicited data
>                     [email-masked]
> 
> 
>                     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" <[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: Paul Koning <[email-masked]>
Date: Tue, 4 Dec 2001 13:00:10 -0500 (EST)

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

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

I assume TCP doesn't overcommit, but that doesn't help.  TCP worries
about TCP resources, and iSCSI has to worry about iSCSI resources.
You may be tight on iSCSI resources and still have TCP buffers.

A way to avoid that is to be aware of how TCP manages resources and
manage iSCSI resources "in parallel" and more conservatively.  If so,
then you are never "overcommitted" at the iSCSI level, and you need no
flow control in the first place.

The reason for having iSCSI level flow control is that the above may
not be true -- i.e., TCP may have resources when iSCSI doesn't.  

So those cases where iSCSI flow control adds value are also the cases
where lower layer flow control doesn't protect you from getting in
trouble if you overcommit.  In other words, if you want reliability,
don't overcommit at any layer.

      paul