RE: iSCSI: update on OOO CmdSNs/connection

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

You change it faster than I can read :-) Instead of Read further
you should have said, Read the latest.

Somesh

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Thursday, November 15, 2001 11:15 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: update on OOO CmdSNs/connection
>
>
> Somesh,
>
> Read further - yes it is back a MUST (it does not make sense to make it a
> blanket SHOULD).
>
> Julo
>
>
>
>
> "Somesh Gupta" <somesh_gupta@silverbacksystems.com>
> Sent by: owner-ips@ece.cmu.edu
> 15-11-01 20:54
> Please respond to somesh_gupta
>
>
>         To:     <ips@ece.cmu.edu>
>         cc:
>         Subject:        RE: iSCSI: update on OOO CmdSNs/connection
>
>
>
> Julian,
>
> As was mentioned previously, there is a signficant
> different in how you design for error recovery
> corner cases, and how you design for the main path.
>
> The SHOULD is neither. I would prefer one of the following
>
> 1. Make it a MUST or not mention it at all.
> or
> 2. Make it a negotiable parameter.
>
> The way it is, it does not provide any benefit to
> the initiator (it is a MUST in a very important case),
> and for the target it becomes a nebulous design choice.
>
> Regards,
> Somesh
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Julian Satran
> > Sent: Wednesday, November 14, 2001 5:46 AM
> > To: ips@ece.cmu.edu
> > Subject: RE: iSCSI: update on OOO CmdSNs/connection
> >
> >
> > Somesh,
> >
> > The reason we have put in the SHOULD is that it better reflects what is
> > happening on recovery anyhow.
> > The text also clearly outlines when the SHOULD becomes MUST and that is
> > the case you where concerned about.
> >
> > Regards,
> > Julo
> >
> >
> >
> >
> >
> > "Somesh Gupta" <somesh_gupta@silverbacksystems.com>
> > Sent by: owner-ips@ece.cmu.edu
> > 13-11-01 22:53
> > Please respond to somesh_gupta
> >
> >
> >         To:     "ips" <ips@ece.cmu.edu>
> >         cc:
> >         Subject:        RE: iSCSI: update on OOO CmdSNs/connection
> >
> >
> >
> > Julian,
> >
> > I am surprised to see the text in the latest rev
> > of the doc change as suggested by Mallikarjun.
> > I did not think there was a consensus on this
> > subject.
> >
> > Just because I did not respond to Mallikarjun's
> > last comment publicly should not be construed
> > as agreement. Having the last word is hopefully
> > not assumed to be consensus, otherwise a thread
> > may never end.
> >
> > Somesh
> >
> > > -----Original Message-----
> > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > > Somesh Gupta
> > > Sent: Friday, November 09, 2001 3:26 PM
> > > To: ips
> > > Subject: RE: iSCSI: update on OOO CmdSNs/connection
> > >
> > >
> > > Mallikarjun,
> > >
> > > I never liked the SHOULD. It is not a design point.
> > > If we really want to allow it, perhaps a negotiation
> > > parameter is a better choice (which is only
> > > marginally better). Error detection and recovery
> > > have completely different design requirements than
> > > the data path.
> > >
> > > So ideally we say MUST or nothing
> > > or we negotiate it
> > >
> > > Also on your point A, it "MUST" be a MUST on
> > > a single connection case except for when required
> > > for error recovery (i.e. the very very rare -
> > > case of digest error).
> > >
> > > Somesh
> > >
> > > > -----Original Message-----
> > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf
> Of
> > > > Mallikarjun C.
> > > > Sent: Friday, November 09, 2001 1:49 PM
> > > > To: ips
> > > > Subject: iSCSI: update on OOO CmdSNs/connection
> > > >
> > > >
> > > > To those interested in this discussion:
> > > >
> > > > Julian and I had a phone conversation on the topic
> > > > of OOO CmdSNs on a connection.  An update follows.
> > > >
> > > > Julian agrees that there are valid error recovery
> > > > scenarios where CmdSNs will legitimately end up OOO
> > > > on a given connection.
> > > >
> > > > OTOH, I agree with two of Julian's scenarios that he
> > > > pointed out right away - the "cleaning command" (command
> > > > required to be sent after a retry copy to ensure flushing
> > > > within 2^31 -1), and an immediate Logout posted with
> > > > unacknowledged commands.  Neither of this can be shipped
> > > > OOO - since the former undoes the flushing intent, and
> > > > the latter breaks the rule that nothing more follows a
> > > > Logout on the connection (and troublesome in other ways,
> > > > see below).
> > > >
> > > > In general, I share the concern with Julian that we
> > > > have not closely scrutinized all possibilities.
> > > >
> > > > With that said, something along the following lines
> > > > seemed reasonable -
> > > >
> > > > A)Initiator MUST send commands in increasing order of
> > > >   CmdSN on a connection if both the following are true -
> > > >              - operational ErrorRecoveryLevel is 0,
> > > >              - MaxConnections is negotiated to 1.
> > > > B)In all the other cases, initiator SHOULD send commands
> > > >   in increasing order of CmdSN on a connection.  It is
> > > >   strongly encouraged that commands with out-of-order
> > > >   CmdSNs be sent on a connection only if they are
> > > >   retransmitted commands due to digest error recovery
> > > >   and connection recovery.
> > > >
> > > > I also suggest the following upon further reflection-
> > > >
> > > > C)Add wording in section 2.2.2.1 to mandate that
> > > >   the cleaning command MUST be sent in-order after
> > > >   the retried command.
> > > > D)Warn clearly that sending an immediate Logout command
> > > >   in the presence of other unacknowledged commands MAY
> > > >   create inadvertent discarding of certain commands (even
> > > >   if it is a recovery Logout), and MAY cause protocol
> > > >   errors leading to ungraceful shutdown of the connection.
> > > >
> > > > Hopefully A will bring the determinism that Somesh was
> > > > looking for certain design points.  B describes the more
> > > > general n-connection session case.  C & D are fixes for
> > > > two identfied areas (so far) which will break.
> > > >
> > > > Comments?
> > > > --
> > > > Mallikarjun
> > > >
> > > >
> > > > Mallikarjun Chadalapaka
> > > > Networked Storage Architecture
> > > > Network Storage Solutions Organization
> > > > MS 5668              Hewlett-Packard, Roseville.
> > > > cbm@rose.hp.com
> > > >
> > >
> >
> >
> >
> >
>
>
>
>
>