Re: iscsi : Review Feedback on Rev 11-94.

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

Santosh,

Let me address just this one.

Background:
Rob Elliott, who is one of this WG contributors as well, is working on 
a T10 proposal that some of us are collaborating on.  The commonly 
agreed design principle among this team of participants is that it's best
if the transport protocols do not individually discuss the SCSI object
clearing actions, but rather let SPC-3 do it on a generic "nexus loss"
notification event (which is left for each transport to define).  In keeping 
with that goal, iSCSI now groups all SCSI objects into appendix F.2
with the hope that once T10 approves Rob's proposal into SPC-3, the
table in this section can be done away with.

Now, onto your questions:
> Is the "I_T nexus loss" notification being advocated for iscsi targets or
> initiators or both ? 

Both, the text doesn't (intentionally) mention the "role" aspect at all -
"iSCSI Layer provides the SCSI layer with the....".

>since session
> closure occurs upon the ULP's explicit request to close. Hence, the ULP is
> aware of the loss of nexus.

Not on an Async-solicited single connection session closure.
 
The simplifying design principle I used is to generate a notification whenever
the iSCSI session enters the FREE state.  I think it's much simpler for iSCSI
implementations to always generate a notification upon entering the FREE state.

> Also, can we avoid clearing mode pages in case of session re-instatement ?
> (case a). In case of ErrorRecoveryLevel=0 initiators, on an iscsi error,
> the initiator will log out and re-login, causing a session re-instatement. 

First off, a "log out and re-login" will not cause a session reinstatement.  A
connection failure may.

Secondly, it appears that you're suggesting a special case for clearing mode pages
for a (iSCSI-specific) type of "I_T nexus loss".  This is not possible once the 
SCSI object clearing effects are taken into SPC-3.  Having transport-specific
"I_T nexus loss" notifications defeats the purpose of having one "I_T nexus loss"
event that SCSI ULPs deal with in a consistent way.

Thirdly, what an initiator considers as "session reinstatement" may actually be a new
session establishment effort on the target if it already timed out the previous session 
instance - since the network latency in transporting the reinstatement Login is not 
predictable. IOW, initiators can not make any assumptions about the mode pages 
in any case.  

Lastly, the iSCSI session reaches the FREE state on either end on a session reinstatement.
Again, it's best to always perform the same actions on reaching FREE as mentioned earlier - 
no special-casing.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

> 8) Section 4.3.5.1 [TECHNICAL]
> ------------------------------
> Is the "I_T nexus loss" notification being advocated for iscsi targets or
> initiators or both ? If it is being advocated for the initiator, then, such
> notification is not required upon session closure (case b), since session
> closure occurs upon the ULP's explicit request to close. Hence, the ULP is
> aware of the loss of nexus.
> 
> Also, can we avoid clearing mode pages in case of session re-instatement ?
> (case a). In case of ErrorRecoveryLevel=0 initiators, on an iscsi error,
> the initiator will log out and re-login, causing a session re-instatement. 
> 
> In this case, it is un-necessary to clear the mode page settings, since it 
> causes extra work in the initiator for no reason. 
> (need to apply flow control, notify ULP, re-negotiate mode pages, resume I/Os).
> In this case, the nexus has not really been lost. It has been re-instated.
> Hence, in this case, negotiated mode pages should not be cleared.
>