Subject: Re: iscsi: comments to iSCSI rev 6

From: "Matt Wakeley" <[email-masked]>
Date: Tue, 01 May 2001 16:23:27 -0400

reply from Julian...

-------- Original Message --------
From: [email-masked]
Subject: Re: iscsi: comments to iSCSI rev 6
To: Matt Wakeley <[email-masked]>

Comments in text.

Thanks,
Julo

"Matt Wakeley" <[email-masked]> on 01-05-2001 03:53:24

Please respond to Matt Wakeley <[email-masked]>

To:   IPS Reflector <[email-masked]>
cc:
Subject:  iscsi: comments to iSCSI rev 6

Section 2.2.3:

The AHSLength field where it is requires RISC type processors to shift the
length left by 8 bytes.

+++ good point - I will make length the first field.  +++

Section 2.3.5, 3rd paragraph: contradicts itself.  First it states that a
AHS
header "MUST" be present, then goes on to define what the bi-di read length
is
if the header is not present.  If it's not present, it's a protocol error.

+++ will fix - it MUST be present +++

Section 2.4.1, last sentance: "b0-b3 MUST be 0" s/b "b1-b4 MUST be 0".

+++ will fix +++

Section 2.7.7: why have residual bits/fields in a data PDU?  If there is
residual, then send a status PDU indicating the residual value.

+++ residual counts are not necessarily errors. Interpretation is by target
and many commands for undefined length transfer end having a residual
count. The space is available in the header so I see no point in not
sending the counts.
SAM2 is somewhat ambivalent about overflow though.  +++

Section 2.8.3: Keys not understood by the target should be expicitely
indicated as not being understood.  Silence is not a good way to indicate
that
one does not understand something.  Also, something more ascii friendly
such
as a semi-colon (;) should be used to separate key-value pairs instead of a
null (0x00) character.  This would allow generic text manipulation
libraries
to be used.
+++ generic text manipulation libraries use 0 as an end of string - our
eyes don't :-)
as for keys not understood the intent is to have new or vendor specific
keys not interfering with the old or standrd only implementations
 +++

Section 2.9.3: why "MUST" key-value pairs be returned in the same order
they
were issued?  Seems like a rather strong requirement for no apparent
reason.

+++ I've changed it into lower-case should +++

Section 2.12.3: indicate that the LUN is copied from the NOP-IN.  This is
much
more clear than "the correct value for the task".

+++ and open it up to strange thing like LU5 asking a nop-out to LU7 ? +++

Section 2.14: Why is there no CmdSN for the logout command?  Also, 2 ways
of
performing the same operation (cleaning up) are stated in the 3rd
paragraph.
In the interest of reducing "options", I suggest that one be picked as the
only method.
+++ silly mistake - i've fixed it +++
Section 2.17.4: "The target assigns" should be "The target may assign".
+++ ??? it always put something there +++
Section 6.3 & 6.7.2: why "MUST" a target reissue missing responses?  What
if
it is not able to?  There should be the option to reject the SNACK.
+++ I am counting - you are number 2 +++
Appendix: "Initial Marker-less Interval" - I say again, there should not be
a
"minimum markerless interval".  This should be whatever is negotiated.
+++ The negotiation itself can't proceed if there are markers that nobody
knows how to take out +++

-Matt Wakeley
Agilent Technologies

---

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 7 May 2001 15:08:07 -0700

> 
> Matt,
> 
> > The result may mean the same, but for diagnostic purposes, 
> the only thing you
> > know is you can't do it.  You don't know why.  If you know 
> why, then perhaps
> > you can take corrective action to remedy the problem.
> 
> To help with this issue, I would prefer key=none be required
> to sent, if applicable. That would leave a non response to
> mean only not supported.
> 
> Steve Senum

This really doesn't seem that hard or worth spending much argument
power on.  The advantage of specifying something rather than simply
not responding is for diagnostic purposes and clarity.  You can tell
by looking only at the response PDU what isn't supported or not 
understood.  You don't have to keep around the original request to
perform a 'diff' to understand why things are negotiating.

I agree with Matt.

Paul

+--------------------------+----------------------------+
+ Paul Congdon             + Email: [email-masked] +
+ Hewlett Packard Company  + Mail Stop:  5662           +
+ HP ProCurve Networking   + Phone:  (916) 785-5753     +
+ 8000 Foothills Blvd      + Fax:    (916) 785-5949     +
+ Roseville, CA   95747    + Mobile: (916) 765-4056     +
+--------------------------+----------------------------+

---

From: [email-masked]
Date: Fri, 18 May 2001 06:59:52 +0300

Santosh,

This subject was discussed several times. The reason for using the LUN is
to enable iSCSI proxies (or virtualizing devices) to operate as routers in
the host to LUN direction and have them possibly insert the LUN field in
the LUN to host direction.  It addition it enables tag allocation per LUN
(not per target).

Clearly the LUN could be any other routing tag but the LUN is already a
well understood mechanism and will guarantee interoperability.

I wonder if we should not make the LUN a mandatory field for NOP-out in
general and enable "path checking" up to
the LU when the using proxies.

As for the tag name - it would be missleading as we do not require it to
identify uniquely a task.

Julo

Santosh Rao <[email-masked]> on 04-05-2001 03:07:24

Please respond to Santosh Rao <[email-masked]>

To:   Matt Wakeley <[email-masked]>, Julian
      Satran/Haifa/IBM@IBMIL
cc:   IPS Reflector <[email-masked]>
Subject:  Re: iscsi: comments to iSCSI rev 6

Matt Wakeley wrote:

> > much more clear than "the correct value for the task".
> >
> How will that occur?  The target sent the NOP-IN ping request.  The
target
> includes a LUN.  The only "correct value" that the initiator can return
for
> the LUN in the NOP-OUT ping response is the value the target sent in the
> original request.

Julian,

Re-wording the LUN descriptions in NOP-IN & NOP-OUT to read that
initiators MUST echo the LUN field from a received NOP-IN into a NOP-OUT
is a more clear and un-ambiguous definition than the current text.

That said, I still continue to have reservations about the need for a
LUN field in a non-SCSI PDU. Fibre Channel does not use the LUN field in
its ELS' & BLS'. LUN is a SCSI construct and it must not be used in
non-scsi PDUs.

I'm yet to hear strong reasons why LUN is required in the NOP-IN or
NOP-OUT. The originator of the NOP operation must generate task tags
independent of LUNs for non-SCSI PDUs. Such PDUs have no scsi context.

As a side cosmetic comment, can we re-name "Target Transfer Tag" to
"Target Task Tag" to have symmetry with the use of Initiator Task Tag ?

- Santosh
 - santoshr.vcf