Reservations discussion posted

Mallikarjun C. cbm at
Thu Feb 28 09:56:17 PST 2002

* From the T10 Reflector (t10 at, posted by:
* "Mallikarjun C." <cbm at>

Sorry, it took us a while to complete revision 1 of the proposal.
It is now uploaded to the T10 website:

This answers your question on the need to terminate the tasks
on session termination.  The related text of the updated draft is
attached below.

I would like us to discuss this updated draft if possible in the
SRP conf call tomorrow.


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

----- Original Message -----
From: "Simpson, Cris" <cris.simpson at>
To: <t10 at>
Cc: <cbm at>
Sent: Wednesday, February 27, 2002 5:32 PM
Subject: RE: Reservations discussion posted

> Mallikarjun,
> > I uploaded the "Reservations & Nexus" discussion
> > paper to the T10 website over the weekend.
> >
> >
> >
>  Could you clarify the second bullet of the Option A 'Cons'?
>      * Does not address the requirement that all tasks be
>        terminated deterministically on both ends when the
>        "login session" collapses for networked transports.
>   Where is this requirement stated?
>   What exactly does "terminated deterministically on both ends" mean?
> Thanks,
> Cris
> --
> Cris Simpson                                          503.712.4333
> Intel EPG/ACD Architecture                           Hillsboro, OR
> PGP Fingerprint:0DA0 418E A27B 0B76 5F02  3DD4 0546 6D13 F88A 1E60

3.2.2.Active tasks must be terminated when a transport session collapses

If tasks were to exist beyond a session failure, they would find themselves stranded
on the target,

which has no clue as to the expected lifetime of each of the tasks. The session
failure however

does not present any serious issues on the initiator - each task times out
individually and the

appropriate task cleanup happens.

A target really has only two alternatives to deal with a set of stranded tasks -

. terminate all the tasks along with the session failure - which is what FCP-2
specifies, and so

does iSCSI.

. timeout the tasks after "sometime"

(a) There is no SCSI-level way of conveying the expected lifetime for the tasks from
the ini-tiator

- so the "sometime" is undefined, and likely to be implementation or even context


(b) Assuming that target picked an arbitrary value, this is an asymmetric timeout -
the initia-tor

may have terminated tasks long before the target did, and could re-use the same task

tags (FC FQ_XID, or iSCSI ITT) on a new instantiation of the I_T_L nexus causing

conflicts with target view. Or worse still, the initiator may attempt to continue the

on a new instantiation of the I_T_L nexus when the target had already terminated

Terminating the active tasks with the transport session failure/closure is the only
decent choice.

This paper explores the right object relationships that result in this desired

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list