Re: Asynchronous Message: Session Termination

[Mark Bakke <mbakke@cisco.com>]

Santosh-

I agree with all of your proposed modifications; that's what
I had in mind as well.  Codes 3 and 4 will then do a better job
of code 2 (target requests logout), so 2 can be removed.

I also think that we should be more specific on
"... will drop all connections" and say
"... will drop all connections within the current session".
I think that was implied, but it is probably better to
explicitly state it.

I agree with both you and Julian that the statement about initiators
modifying these time values should be removed; I think that these
time values are really up to the target, and we should remove
them from the negotiation.

--
Mark

Santosh Rao wrote:
> 
> Julian,
> 
> The modified text on "Async Message" seems to have missed out several
> aspects of the discussion on this thread :
> 
> 1) It is useful to provide a parameter for the "target will drop this
> connection" and "target will drop all connections" to indicate the time,
> in seconds, after which the target would drop the connection[s].
> 
> This allows :
> 
> - the target to warn the initiator ahead of time about an upcoming
> disruption so that initiator can take action accordingly.
> 
> - Allows elimination of the "target requests logout" option since the
> "will drop connection/all connections" flavor provides the initiator an
> upper time bound after which the connection[s] are going to be dropped.
> This allows the initiator to attempt to quiesce the connection[s] prior
> to the expiry of that time period. The "target requests logout" option
> should be removed, if its equivalent functionality or better can be
> provided by the "will drop connection/all connections" flavors.
> 
> 2) Suggest modification of the below wording :
> " If the initiator does not attempt to reconnect within the time
> specified by Parameter 3 or Parameter 3 is 0 the session is terminated -
> in which case no other responses should be expected from the target for
> outstanding commands on this session and the initiator should terminate
> them appropriately."
> 
> to indicate that upon expiry of the LogoutLoginMaxTime (parameter 3),
> the target internally aborts all outstanding commands on that connection
> and the initiator should consider those I/Os implicitly aborted. No
> explicit Abort mechanisms are required from the initiator to the target
> upon expiry of LogoutLoginMaxTime to terminate these commands.
> 
> 3) The "target will drop all connections" flavor description should
> indicate that the target is performing a session logout. I like the
> parameter descriptions provided by Mark [Bakke] for this flavor, namely
> :
> 
> - Parameter2 indicates the time, in seconds, after which the target will
> drop all connections.
> - Parameter3 indicates the additional time, in seconds, after the expiry
> of Parameter2, that the initiator must wait before attempting to
> re-establish a session.
> 
> The LogoutLoginMaxTime in the current defn of "target will drop all
> connections" (Parameter 3) provides little value, since the target
> should be aborting all oustanding I/O as a part of that session logout
> and not wait until LogoutLoginMaxTime.
> 
> 4) Regarding :
> "Initiators can attempt to set/modify the values a target will use for
> Parameter2 and Parameter3. However - I am unclear if we should leave the
> initiator the degree of control implied by (innocuous looking) last
> statement."
> 
> Since, LogoutLoginMaxTime & LogoutLoginMinTime are only applicable in
> the context of a target originated "connection drop" as indicated by the
> async events, these keys add little or no value in the login
> negotiation. In all cases, it is the time values provided by the target
> in the async events that are applicable and over-ride any login
> negotiated values for these keys. Hence, should these keys be removed
> from the login negotiation ?
> 
> Regards,
> Santosh
> 
> julian_satran@il.ibm.com wrote:
> >
> > Mathhew, Mark, Matt & Santosh:
> >
> > Here is the new text for 2.17.1
> >
> > 1.1.1     iSCSI Event
> >
> >    The codes used for iSCSI Asynchronous Messages (Events) are:
> >
> >       0    No iSCSI Event
> >       1    Target is being reset.
> >       2    Target requests Logout - the Parameter1 field indicates on what
> >       CID.
> >       3    Target indicates it will drop the connection - the Parameter1
> >       field will indicate on what CID while the Parameter2 field indicates,
> >       in seconds, the minimum time to wait before attempting to reconnect
> >       and Parameter3 the maximum time to reconnect  after the initial wait
> >       (Parameter2). If the initiator does not attempt to reconnect within
> >       the time specified by Parameter 3 or Parameter 3 is 0 no other
> >       responses should be expected from the target for outstanding commands
> >       on this connection and the initiator should terminate them
> >       appropriately. A value of 0 for Parameter 2 indicates that reconnect
> >       can be attempted immediately.
> >       4    Target indicates it will drop all connections - the Parameter2
> >       field indicates, in seconds, the minimum time to wait before
> >       attempting to reconnect and Parameter3 the maximum time to reconnect
> >       after the initial wait (Parameter2). If the initiator does not
> >       attempt to reconnect within the time specified by Parameter 3 or
> >       Parameter 3 is 0 the session is terminated - in which case no other
> >       responses should be expected from the target for outstanding commands
> >       on this session and the initiator should terminate them
> >       appropriately.  A value of 0 for Parameter 2 indicates that reconnect
> >       can be attempted immediately.
> >
> >       Initiators can attempt to set/modify the values a target will use for
> >       Parameter2 and Parameter3
> >
> >       However - I am unclear if we should leave the initiator the degree of
> >       control implied by (innocuous looking) last statement.
> >
> >       Thanks for helping make this text better.
> >
> >       Julo

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054