RE: iSCSI: update on OOO CmdSNs/connection

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

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