Re: iSCSI: unsolicited data

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

> Unsolicited data needs are very hard to predict and ordering them may
> remove the need to do so to a large extent.

Completely agreed.  There are obvious performance advantages in mandating
order, as earlier discussions clearly outlined.  I am not questioning it.

I however could not really see a deadlock per se - my comment was to
understand
what it is.    More comments would certainly help.

> As for the action - yes we may want to weaken the requirement to
> accommodate for digest errors.

Thanks.  I meant to weaken the requirement on the response to a UUD, not
the ordering requirement itself.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747


----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Monday, November 26, 2001 10:23 PM
Subject: Re: iSCSI: unsolicited data


> 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.
> As for the action - yes we may want to weaken the requirement to
> accommodate for digest errors.
>
> Regards,
> Julo
>
>
>
>
>
>
>
> "Mallikarjun C." <cbm@rose.hp.com>
> Sent by: owner-ips@ece.cmu.edu
> 26-11-01 21:45
> Please respond to cbm
>
>
>         To:     ips <ips@ece.cmu.edu>
>         cc:
>         Subject:        iSCSI: unsolicited data
>
>
>
> Julian,
>
> I don't recall the earlier discussion being conclusive on this topic,
> so let me attempt to make a couple of suggestions on this.
>
> Last para in Section 2.2.5 (page 33) in rev09 mandates unsolicited
> data ordering with the following wording.
>
>   "iSCSI initiators and targets MUST also enforce some ordering rules to
>    achieve deadlock-free operation. Unsolicited data MUST be sent on
>    every connection in the same order in which commands were sent. A
>    target receiving data out of order SHOULD terminate the session."
>
> I have a couple of suggestions to reword -
>
> - The reference to a deadlock is true only for an implementation
>   overcommitting the unsolicited data buffers.  So, I would suggest
>   dropping this reasoning.
>
> - The "MUST enforce"  wording should also add that "targets MAY
>   however see unexpected unsolicited data (UUD), following data
>   digest errors on expected unsolicited data."
>
> - Finally, the "SHOULD terminate the session", IMHO, is too strong.
>   This wording will imply that a session is vulnerable to a single
>   digest error regardless of recovery level.  [ I however disfavor
>   attaching more assorted semantics to recovery levels (than the
>   current easily understood "level = setof(recovery classes)"
>   formulation). ]  As you mentioned on this discussion earlier, a
>   UUD is a protocol error (or may be not, if it is the effect of
>   a prior digest failure).
>
>   We can choose to Reject ("protocol error") the UUD and discard the
>   data.  The only problem with this approach is: following a digest
>   error on unsolicited data for one task, all the following unsolicited
>   data in flight would have to be discarded.  One option is to imply
>   that the target update the "expected unsolicited data"  so the
>   unsolicited data following in the pipe can be processed normally.
>   So, I guess it would be saying: "the target MAY Reject the UUD".
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668          Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
>
>