RE: iSCSI: update on OOO CmdSNs/connection

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

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