Return-Path: <owner-ips-outgoing@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips-outgoing@ece.cmu.edu>
Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h460oU319221
	for <ipsml@ece.cmu.edu>; Mon, 5 May 2003 20:50:30 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix, from userid 953)
	id D824679; Mon,  5 May 2003 20:50:29 -0400 (EDT)
Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27])
	by hazard.ece.cmu.edu (Postfix) with ESMTP
	id 43D2B63; Mon,  5 May 2003 20:50:22 -0400 (EDT)
Received: by sos.ece.cmu.edu (Postfix)
	id BAB788965; Mon,  5 May 2003 20:50:08 -0400 (EDT)
Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24])
	by sos.ece.cmu.edu (Postfix) with ESMTP id AD9228963
	for <ips-outgoing@sos.ece.cmu.edu>; Mon,  5 May 2003 20:50:08 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix)
	id 963D06A; Mon,  5 May 2003 20:50:08 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix, from userid 953)
	id 7642A63; Mon,  5 May 2003 20:50:08 -0400 (EDT)
Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27])
	by hazard.ece.cmu.edu (Postfix) with ESMTP id 36F5663
	for <ips-outgoing@ece.cmu.edu>; Mon,  5 May 2003 20:50:05 -0400 (EDT)
Received: by sos.ece.cmu.edu (Postfix, from userid 363)
	id EFF2D8966; Mon,  5 May 2003 20:50:04 -0400 (EDT)
X-Original-To: ips@sos.ece.cmu.edu
Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24])
	by sos.ece.cmu.edu (Postfix) with ESMTP id 499368963
	for <ips@sos.ece.cmu.edu>; Mon,  5 May 2003 20:50:03 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix)
	id 0C48063; Mon,  5 May 2003 20:50:03 -0400 (EDT)
Delivered-To: ips@ece.cmu.edu
Received: by hazard.ece.cmu.edu (Postfix, from userid 953)
	id DAE5F70; Mon,  5 May 2003 20:50:02 -0400 (EDT)
Received: from mail.ivivity.com (unknown [64.238.111.99])
	by hazard.ece.cmu.edu (Postfix) with ESMTP id 3FAF06A
	for <ips@ece.cmu.edu>; Mon,  5 May 2003 20:49:59 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2653.19)
	id <2CY0SVHV>; Mon, 5 May 2003 20:49:59 -0400
Message-ID: <AEC4671C8179D61194DE0002B328BDD26A7D35@ATLOPS>
From: Eddy Quicksall <eddy_quicksall@ivivity.com>
To: wrstuden@wasabisystems.com, Eddy Quicksall <eddy_quicksall@ivivity.com>
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: clearing SCSI objects
Date: Mon, 5 May 2003 20:49:51 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
X-Spam-Status: No, hits=-22.6 required=5.0
	tests=BAYES_01,EMAIL_ATTRIBUTION,ORIGINAL_MESSAGE,
	      QUOTED_EMAIL_TEXT
	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)

If you have persistent reserves, you will lose them.

Keeping them around in the absence of persistent reserves is for full
compliance and it is easy to do.

Eddy

-----Original Message-----
From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] 
Sent: Monday, May 05, 2003 7:14 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: clearing SCSI objects

On Mon, 5 May 2003, Eddy Quicksall wrote:

> If you don't worry about it, you will either have to:
>
> 1) have lots of initiator structures available
> 2) not support multiple Initiator Ports
> 3) not be fully SCSI compliant
>
> The Microsoft Initiator will use a different ISID each time it logs on. It
> will log on with each boot and there is no guarantee that it will use the
> same ISID set with each boot. I think multiple applications will also be
> able to login at the same time ... each with a different ISID. If they
login
> and logout with execution, you may run our of structures

?? Huh?

I was suggesting not worrying about keeping resources around to tell an
initiator it lost the I_T nexus when it already knows it lost the I_T
nexus. How will that mean I'll run out of resources?

Take care,

Bill

> -----Original Message-----
> From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]
> Sent: Monday, May 05, 2003 6:50 PM
> To: Eddy Quicksall
> Cc: David Black (Black_David@emc.com); ips@ece.cmu.edu
> Subject: RE: iSCSI: clearing SCSI objects
>
> On Sun, 4 May 2003, Eddy Quicksall wrote:
>
> > David,
> >
> > I'm wondering what other targets are doing about this. Was it thought
> about
> > during the design phase?
>
> Our (Wasabi's) target isn't going to do this, unless there is a strong
> indication that it's needed/required for certification. I see no real
> reason to do this as it's not conveying any value.
>
> > I'm thinking I will keep an LRU list and if I run out of structures to
> > handle SCSI Initiator Ports (and there are no persistent reserves
> > outstanding), I'll just discard the oldest structure. That will give a
> power
> > on reset UA if that InitiatorName+ISID is used again.
> >
> > Does that seem like a logical solution?
>
> I think it's far simpler to not worry about it, or be clearer about when
> we worry about it. SAM was written with parallel and FC SCSI in mind.
> While there are obvious references to iSCSI, we are only now gaining
> experience about what needs tweaking in light of iSCSI.
>
> I'd say start with asking why SAM says the target needs to set a UA, and
> see if that applies here. It's my understanding that parallel SCSI has no
> way for the target to asynchronously just tell the initiator something.
> Likewise, the initiator has no way to directly notice the loss of an I_T
> nexus.
>
> iSCSI, though, doesn't have those limitations. For instance, we can send
> Asynchronous messages with SCSI sense data. We also have one or more TCP
> connections, and rules for adding connections to a session. The up-shot is
> that the initiator will realize if it looses the I_T nexus due to
> transport issues. For instance, when it goes to add a connection to a
> session, it will be told that no such session exists (top of page 60 in
> draft 20) -> the session (I_T nexus) is dead. Alternately if the initiator
> chooses to do session reinstatement, it knows it is loosing the old I_T
> nexus (that's what it's telling the target to do, after all :-) .
>
> So I'd think that the best thing to do here is push back on SAM for iSCSI,
> and ignore the need to assert the UA for I_T nexus loss in the cases where
> the initiator will notice it itself.
>
> Note I'm hedging my words, since I think we still need a UA for nexus loss
> if it happens in a way the initiator won't notice.
>
> Thoughts?
>
> Take care,
>
> Bill
>
