[Fwd: Re: iSCSI: connection timeout mgmt - clarifications/changes]

["Mallikarjun C." <cbm@rose.hp.com>]

All,

Please find the attached email that details the proposed text changes
for rev11.

Except the renaming of two text keys (details below), the proposed
changes are
all clarifications and corrections of current text.  Hopefully, the
changes would
bring clarity on how to use the different connection timeouts that the
draft defines.

Thanks.
 --
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747


-------- Original Message --------
Subject: Re: timers
   Date: Thu, 14 Feb 2002 09:31:33 +0200
   From: "Julian Satran" <Julian_Satran@il.ibm.com>
     To: "Mallikarjun C." <cbm@rose.hp.com>



Excellent - Julo


  "Mallikarjun C."
  <cbm@rose.hp.com>                     To:        Julian
                                Satran/Haifa/IBM@IBMIL
  14-02-02 05:19                        cc:
                                        Subject:        Re: timers



Julian,

Here is the new text per our phone conversation today on the
ERT proposal to add a new section to Error Recovery.  To
summarize -
   - LogoutLoginMaxTime & LogoutLoginMinTime are respectively
      renamed as DefaultTime2Retain and DefaultTime2Wait since they
      are no longer related to Logout per se, and also to align the
names
      better with the Time2Wait and Time2Retain ideas
   - The new text for these keys makes it clear that only the implicit
      connection logout and the task reassignment are constrained by
      Time2Wait.  Adding a new connection with a new CID is not
      constrained.
   - Clarified the wording in Logout Response section for Time2Wait
      and Time2Retain.
   - Added a new section in the Error Recovery chapter on usage
     of these different timeout values.

Attached are the sections of new/changed text.  Please comment, and feel
free
to forward to the ips list if you're in agreement.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747

-------------------------------------------------------------------------------------

-
12.15 DefaultTime2Wait
Use: LO
Senders: Initiator and Target
Scope: SW
DefaultTime2Wait=<number-0-to-3600>
Default is 3.
The initiator and target negotiate the minimum time, in seconds, to
wait before attempting an explicit/implict logout or active task
reassignment after an unexpected connection termination or a connec-tion

reset.

The higher of the two values is selected.

A value of 0 indicates that logout or active task reassignment can be
attempted immediately.

12.16 DefaultTime2Retain
Use: LO
Senders: Initiator and Target
Scope: SW
DefaultTime2Retain=<number-0-to-3600>
Default is 3.
The initiator and target negotiate the maximum time, in seconds after
an initial wait (Time2Wait), before which an explicit/implicit
con-nection
Logout or active task reassignment is still possible after an
unexpected connection termination or a connection reset.

This value is also the session state timeout if the connection in
question is the last LOGGED_IN connection in the session.
The lesser of the two values is selected.

A value of 0 indicates that connection/task state is immediately
dis-carded
by the target.
--------------------------------------------------------------------------------

7.3 Connection timeout management
iSCSI defines two session-global timeout values (in seconds) -Time2Wait
and Time2Retain - that are applicable when an iSCSI full-feature
phase connection is taken out of service either intentionally
or on an exception. Time2Wait is the initial "respite time" before
attempting a connection reinstatement for the CID in question and/or
task reassignment for the affected tasks (if any). Time2Retain is the
maximum time after the initial respite interval that the task and/or
connection state(s) is/are guaranteed to be maintained on the target
to cater to a possible recovery attempt.

7.3.1 Timeouts on transport exception events
A transport connection shutdown or a transport reset without any
preceding iSCSI protocol interactions informing of the fact causes a
full-feature phase iSCSI connection to be abruptly terminated. The
timeout values to be used in this case are the negotiated values of
DefaultTime2Wait (Appendix 12.15) and DefaultTime2Retain (Appendix
12.16) text keys for the session.

7.3.2 Timeouts on planned decommisioning
Any planned decommisioning of a full-feature phase iSCSI connection
is preceded by either a Logout Response PDU, or an Async MessagePDU.
The Time2Wait and Time2Retain field values (section 10.15)in a Logout
Response PDU, and the Parameter2 and Parameter3 fields of an Async
Message (AsyncEvent types "drop the connection" or "drop all the
con-nections";
section 10.9.1) specify the timeout values to be used in
each case.

These timeout values are applicable only for the affected connection,
and the tasks active on that connection. These timeout values have no
bearing on initiator timers (if any) that are already running on
con-nections
or tasks associated with that session.
------------------------------------------------------------------------------

10.15.2 Time2Wait
If the Logout response code is 0 and if the operational
ErrorRecovery-Level
is 2, this is the minimum amount of time, in seconds, to wait
before attempting task reassignment. If the Logout response code is 0
and if the operational ErrorRecoveryLevel is less than 2, this field
is to be ignored.

This field is invalid if the Logout response code is 1.

If the Logout response code is 2 or 3, this field specifies the mini-mum

time to wait before attempting a new implicit or explict logout.

If Time2Wait is 0, the reassignment or a new Logout may be attempted
immediately.

10.15.3 Time2Retain
If the Logout response code is 0 and if the operational
ErrorRecovery-Level
is 2, this is the maximum amount of time, in seconds, after the
initial wait (Time2Wait), the target waits for the allegiance
reas-signment
for any active task after which the task state is discarded.
If the Logout response code is 0 and if the operational
ErrorRecovery-Level
is less than 2, this field is to be ignored.

This field is invalid if the Logout response code is 1.

If the Logout response code is 2 or 3, this field specifies the maxi-mum

amount of time, in seconds, after the initial wait (Time2Wait),the
target waits for a new implicit or explict logout.

If it is the last connection of a session, the whole session state is
discarded after Time2Retain.

If Time2Retain is 0, the target had already discarded the connection
(and possibly the session) state along with the task states. No
reas-signment
or Logout is required in this case.