Subject: RE: iSCSI: ISIDs

From: "Julian Satran" <[email-masked]>
Date: Tue, 11 Sep 2001 11:15:34 +0300

that sounds far better - julo

Jim Hafner/Almaden/IBM@[email-masked] on 10-09-2001 18:38:50

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  [email-masked]

To:   [email-masked], [email-masked]
cc:
Subject:  RE: iSCSI: ISIDs

David and Julian

On second thought, let me qualify what I just said in my last posting about
recreating the session on a different portal group.

As far as the model is concerned, that still holds, BUT it doesn't prevent
failover from one HBA to another!  The reason is that all of the properties
of the failed HBA can be assumed by the back up HBA (this includes,
ipaddresses, portal group tag, etc.).  So, phyically, the HBA may be a
different one, but the model view of the portal group is still the same
(different hw, same 'identity').   Similar things happen with just IP
addressing today and with FC functions as well.

Jim Hafner

[email-masked]@ece.cmu.edu on 09/09/2001 11:16:39 pm

Sent by:  [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: iSCSI: ISIDs

One more whack at this ...

> The major difference is "control". In the current scheme the initiator
and
> target could independently allocate and reuse their parts.
>
> The target allocates only scheme leaves this to the target (it has to do
> garbage collection) under the assumption that the target (unlike the
> initiator) has a central point of control.

Yes, I'm assuming that targets will have a single vendor in charge
of all the software on the target and making it work right if there are
multiple HBAs; I don't see any corresponding vendor who's in a position
to do the same for the initiator ...

> Aren't targets going to have several HBA and have to carefully allocate
> their SSIDs?

But they'll have one vendor in charge of making this work.  In contrast,
for an initiator with HBAs from two different vendors, both of those
vendors and the vendor of the OS platform have to be involved, and I
don't see any of them taking full responsibility in the early going.
I'm worried we risk heading the iSCSI Initiator Name down the same
path as Fibre Channel, where the FC Node WWN was supposed to be associated
with the server into which the HBAs were plugged, but got associated
with the HBA because there was no way to coordinate across HBAs.
If anything ever goes wrong with ISIDs (and things will), the fastest
way to fix it will be to require each HBA to have its own iSCSI Initiator
Name, independent of the intent of the iSCSI naming architecture.

> In the event an initiator wants to rebuild a session does he have to
> connect to the same HBA and thus a failover to another HBA
> can't be done.

No, this is controlled by portal groups.  To failover across two HBAs
on the target, they have to be in the same portal group, and the target
is responsible for coordinating TSID usage within each portal group.
If the target can't coordinate TSID usage, it puts the HBAs into different
portal groups and gives up this failover ability as a consequence, and
that's the case independent of whether ISIDs exist or not.

> For all the above no to happen we have to add some management somewhere
and
> it looks to me that the current scheme is simpler than a target centric
one
> as it keeps the allocation and release of numbers at the same end.

I'm sorry, that doesn't parse for me.  It looks like the same sort of
mechanism is being put into both initiators and targets for symmetry,
without considering whether two instances of the mechanism are actually
necessary.  In a target-centric scheme, the target is doing the "allocation
and release" of numbers.  The target does have to be careful about not
aggressively reusing TSID values, when there's potentially recoverable
state around (or the initiators may think that there's state to be
recovered even though the target's lost it all in a reboot), but recall
that aggressive reuse of ISIDs is what created the Option A/B/C mess
(and not aggressively reusing ISIDs would make that easier to solve).
I don't understand how two instances of similar mechanisms is "simpler"
than one.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Robert D. Russell" <[email-masked]>
Date: Wed, 12 Sep 2001 10:44:25 -0400

Julian:

I would like to request 3 small changes in the format of some of
the PDUs.  One of the design features that you have employed
very successfully to date is to have a given field, such as the
"Initiator Task Tag" for example, always appear in the same position
(bytes 16-19) in any PDU in which it appears.  This makes it easy
to understand, to implement, and to debug.  However, a few small
inconsistencies in the application of this design principle have
crept in with draft 7, and I would like to propose that we fix them.

1.  In draft 6 the SCSI Response PDU had one Status/Response field
	in byte 3 -- in draft 7-90 it now has a Status field in byte 2
	and a Response field in byte 3.  In draft 6 the Data-in PDU also
	had a Status field in byte 3, and in draft 7-90 it is still in
	byte 3, with byte 2 unused (reserved).  Would you please either:

	a.	Reorder the bytes in the SCSI Response PDU so that the Status
		field will be in byte 3 (so it is consistent with the Data-in
		PDU) and the Response field will be in byte 2; or

	b.	Move the status field in the Data-in PDU from byte 3 to byte 2
		(so it remains consistent with the SCSI Response PDU).

	I would prefer alternative a. because it would leave the Data-in
	PDU unchanged for drafts 6, 7 and 8, and the SCSI Response PDU
	has to change in any case.  However, obviously either solution
	would work.

2.	In draft 7-90, a field called "Response" appears in 3 PDUs:

	a.	In byte 36 of the Task Management Response PDU.
	b.	In byte 36 of the Logout Response PDU.
	c.	In byte 2 (if my request 1a above is taken) in the
		SCSI Response PDU.  This is clearly inconsistent with a and b.

	Since bytes 2 and 3 are currently unused (reserved) in both
	the Task Management Response PDU and the Logout Response PDU,
	the simplest solution would be to move the "Response" field in
	those 2 PDUs to byte 2 in order to be consistent with the SCSI
	Response PDU.  To keep the design clean, the new "Qualifier" field
	in the Task Management Response PDU should probably also be
	moved to byte 3.

3.	In draft 7-90 the Login and Login Response PDUs have been modified
	with the introduction of the T, C, and CNxSG fields in byte 37.
	However, in the Login Response PDU these fields overlay the
	Status-Detail field, which is also in byte 37.  Although the way
	to interpret this field is uniquely determined by the context,
	it is context dependent and I believe that this will lead to a lot
	of needless errors in coding, and that it also makes debugging more
	difficult, because the use of this byte changes during the login phase
	exchanges.  This means that you can't always look at it the same way.
	To avoid this overlay, would you please move the new fields
	(T, C, and CNxSG) to one of the currently unused bytes.  Many bytes
	(2, 10-11, 20-23, 38-39, 40-47) are currently unused in both of these
	PDUs, so there would appear to be no urgent need to overlay the new
	fields on top of an existing field in order to save space.

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

---

From: "Ayman Ghanem" <[email-masked]>
Date: Wed, 12 Sep 2001 17:15:39 -0500

I agree with 1 and 2, but I still prefer to overlap Status-Detail with the
T/C/CNxSG in the same byte for the same reason behind changes 1 and 2. Both
fields provide login response status details, with meaning interpreted
differently based on the Status-Class.

-Ayman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Robert D. Russell
> Sent: Wednesday, September 12, 2001 9:44 AM
> To: Julian Satran
> Cc: [email-masked]
> Subject: RE: iSCSI: PDU formats
>
>
> Julian:
>