Re: Asynchronous Message: Session Termination

[Santosh Rao <santoshr@cup.hp.com>]

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
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard