Re: Target Reset handling

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

Julian,

Let me try again, I was arguing that the protocol stack (I assume you
mean the state information in various layers by this) and the TCP
connections be *not* reset - since I do not see a need for the SCSI
transport mechanism to be reset/cleared in the context of "SCSI target
reset".  I would again request your attention on the FC precedent, and
the software expectations of a confirmed target reset.  Logging in after
an arbitrary "long time" and assuming the target reset to be complete is
simply unreliable.

I do not see a need for a special "iSCSI reset".  I believe that the
SCSI target reset task management request is completely adequate to
address our requirements.  All I am proposing is a change in its current
definition in view of the various reasons I had already stated, and the
benefits of making this change (not the least of which is SAM-2
compliance).  Addition of a new reset mechanism would also defeat our
common goal to keep a fairly lean protocol.

The question of security context needs to addressed regardless of the
SCSI transport behavior on a target reset.  If security context is being
designed as part of the transient operating environment (as opposed to
say, creating/modifying mode pages), then my first guess would be that
it has to be reset as well to initial values, on a target reset.  I am
not sure what you implied, but are you suggesting that the security
context cannot be reset with TCP connections living across a SCSI target
reset?  Or, did I totally miss something?

Regards.

Mallikarjun
M/S 5601
Networked Storage Architecture
HP Storage Organization
Hewlett-Packard, Roseville.
cbm@rose.hp.com


julian_satran@il.ibm.com wrote:
> 
> Mallikajun,
> 
> Assuming that we leave the connections on - how would you suggest we reset
> the protocol stack and the connections?
> 
> Is adding a new iSCSI reset better?
> 
> Should the target imply a reset when all connections drop and a new session
> get's established or a long time passes?
> 
> What happens to the security context across a reset?
> 
> I have the feeling that answers to those questions will complicate the
> reset handling
> far beyond what the technical community will find acceptable.
> 
> Julo
> 
> "Mallikarjun C." <cbm@rose.hp.com> on 01/09/2000 20:31:39
> 
> Please respond to cbm@rose.hp.com
> 
> To:   ips@ece.cmu.edu
> cc:    (bcc: Julian Satran/Haifa/IBM)
> Subject:  Re: Target Reset handling
> 
> Julian,
> 
> I agree with you that the interactions should be left as simple
> as possible, but I strongly believe that a response to a target
> reset is highly desirable and very useful.  Besides, my reading
> of SAM-2 (as quoted below) indicates that a response is required.
> 
> While SAM-2 leaves the definition of the target reset process to
> the specific SCSI protocol and interconnect, I would argue that in
> the case of iSCSI, resetting the entire TCP/IP stack and tearing
> up the TCP connections should not be necessary.  It would seem that
> the SCSI operational portion (task manager, device server(s), and
> the tasks themselves) should be affected by a SCSI target reset.
> As I recall, this is the approach FC target implementations took
> leaving the process login sessions intact.  Having the TCP connections
> operational would allow us to -
>      - reliably deliver the AEN to all the iSCSI-logged-in initiators.
>      - deliver a response to target reset task mgmt request
> 
> There's a fair amount of SCSI/LVM software that relies on a reliable
> target reset confirmation, and an out-of-band confirmation of the
> same would not go well with it.
> 
> Regards.
> --
> Mallikarjun
> M/S 5601
> Networked Storage Architecture
> HP Storage Organization
> Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> >Mallikarjun,
> >
> >We assumed that a reset for a controller including such a complex piece
> >of code/hardware as protocol stack is never complete without resetting it
> >too.
> >making AE signalling mandatory is not big help as they might get lost
> >if done before the connections break. But if the group feels we should
> make
> >it mandatory we will.
> >
> >For any simple minded (minimalist design) a protocol function
> >that does what a reset button would do should be enough.
> >
> >For complex controllers you can choose to:
> >
> >- record the reset results in NV store and report them during the next
> >session
> >or even make reading this log in a sense mandatory through an ACA
> >
> >- report the event through a vendor specific text response to the next
> >login
> >
> >- use management interfaces (SNMP)
> >
> >I personally am inclined to think that the "in-band" rest should be left
> >as simple as possible (but not simpler!) and out-of-band communication
> >should
> >be used to check the process.
> >
> >Regards,
> >Julo
> >