RE: iSCSI: update on OOO CmdSNs/connection

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

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
> > >
> >
>
>
>
>