Re: Asynchronous Message: Session Termination

[julian_satran@il.ibm.com]

Santosh,

Answers in text - Julo

Santosh Rao <santoshr@cup.hp.com> on 25-05-2001 21:32:17

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: Asynchronous Message: Session Termination




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.

+++ the request logout was intended to allow an initiator to quisce
activity.
Having a target - that is unaware of the speed or needs of an initiator
dictate a timeout
does not look like a good solution for a non-urgent case.
Request logout was meant to enable channels to go into maintenance +++

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.


+++ that is the exact meaning of the current wording and the statement that
no other
responses should be expected conveys the behaviour as seen by the
initiator.
However since your reaction indicates that this might still be
misinterpreted i'll change the text to:

      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 the target will
      terminate all outstanding commands on this connection, no other
      responses should be expected from the target for the outstanding
      commands on this connection and the initiator should generate the
      appropriate responses. 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 this case the target
      will terminate all outstanding commands in this session, no other
      responses should be expected from the target for the outstanding
      commands in this session and the initiator should generate the
      appropriate responses.   A value of 0 for Parameter 2 indicates that
      reconnect can be attempted immediately.

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.
+++ the point is that the target is not performing a session logout but is
rather droping all connections and
may wish to establish new ones without droping the session - that is the
meaning of Parameter3+++

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 ?


+++ they are meant to convey the target what the specific initiator
considers "enough time" and that varies by constituency. ++++

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
 - santoshr.vcf