Subject: [Ips] LUN field in R2T

From: [email-masked]
Date: Wed, 2 Jan 2008 13:27:31 -0500

Just a quick clarification:

10.8.5.  Target Transfer Tag

[...]The Target Transfer Tag and LUN are copied in the outgoing data
PDUs and are only used by the target.

Does this mean that the LUN field in the R2T does not need to contain
the actual LUN number specified by the SCSI write?   Since the field is
"only used by the target" I assume this text means that the target may
place anything it wants in the LUN field of the R2T and have it echoed
back by the initiator.

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: [email-masked]
Date: Wed, 2 Jan 2008 17:19:36 -0500

Hi Bill,

I know from experience that some initiators will fill in the LUN field in 
the data out with the actual LUN specified in the SCSI write. 

While that may not be compliant with 10.8.5, you may see interop problems 
if you're depending on the initiator to echo that LUN back to you.

regards,

david

Java: The elegant simplicity of C++ 
and the blazing speed of smalltalk.

David J Cuddihy
Principal Engineer
ATTO Technology, Inc.
(716) 691-1999 x157 

www.attotech.com
Power Behind the Storage

[email-masked] 
01/02/2008 01:28 PM

To
<[email-masked]>
cc

Subject
[Ips] LUN field in R2T

10.8.5.  Target Transfer Tag
[...]The Target Transfer Tag and LUN are copied in the outgoing data PDUs 
and are only used by the target.
 
Does this mean that the LUN field in the R2T does not need to contain the 
actual LUN number specified by the SCSI write?   Since the field is ?only 
used by the target? I assume this text means that the target may place 
anything it wants in the LUN field of the R2T and have it echoed back by 
the initiator.
 _______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Julian Satran <[email-masked]>
Date: Thu, 3 Jan 2008 14:41:32 +0530

Your interpretation is more liberal than the text says. The reason for 
requiring a LUN field in the first place was to remove the requirement for 
a  target-wide unique TTT and enable distributed targets that do not 
require coordination.  The reason LUN was chosen to tag the R2T is that it 
may simplify routing of the data to the appropriate destination.
But since it is called LUN some zealous initiator may check (although it 
is not mandated) the LUN validity versus a list obtained otherwise - so I 
would not go for a very liberal interpretation.

Julo

[email-masked] 
01/02/08 11:57 PM

To
<[email-masked]>
cc

Subject
[Ips] LUN field in R2T

---

From: [email-masked]
Date: Thu, 3 Jan 2008 16:06:03 -0500

Thanks for getting back on this.   I think I still need a little
clarification.

In a nutshell all I want to know is this:  Is it legal for an initiator
to set the LUN field in the Data-Out PDU based on what it knows the LUN
to be, or MUST the initiator copy the contents of the LUN field from the
received R2T into the Data Out. 

Example:  An initiator negotiates for MaxOutstandingR2T==4.  The
initiator sends a write command to a target.  The initiator receives an
R2T and starts sending multiple Data-Out PDUs.   The initiator receives
3 more R2Ts but cannot start sending Data-Out PDUs immediately due to
outbound resource limitations.   The initiator must now store off each
R2T request so that it can honor them when resources become available -
otherwise the initiator will need to halt receive processing on the
connection.   The initiator will probably need to store the Target
Transfer Tag, Buffer Offset, and Desired Data Transfer Length for each
R2T.   Does the initiator need to store the LUN from each R2T as well?
Or can it just fill in the LUN in the Data Out PDUs based on knowing
what LUN the command was sent to in the first place? 

Thanks,

Bill

________________________________

From: Julian Satran [mailto:[email-masked]] 
Sent: Thursday, January 03, 2008 4:12 AM
To: Sears, Bill
Cc: [email-masked]
Subject: Re: [Ips] LUN field in R2T

Your interpretation is more liberal than the text says. The reason for
requiring a LUN field in the first place was to remove the requirement
for a  target-wide unique TTT and enable distributed targets that do not
require coordination.  The reason LUN was chosen to tag the R2T is that
it may simplify routing of the data to the appropriate destination. 
But since it is called LUN some zealous initiator may check (although it
is not mandated) the LUN validity versus a list obtained otherwise - so
I would not go for a very liberal interpretation. 

Julo 

[email-masked] 

01/02/08 11:57 PM 

To

<[email-masked]> 

cc

Subject

[Ips] LUN field in R2T

  
  
<https://www1.ietf.org/mailman/listinfo/ips>

---

From: Julian Satran <[email-masked]>
Date: Fri, 4 Jan 2008 18:23:47 +0530

Bill,

This is left to the implementer. I would argue that a "liberal" initiator 
should store the LUN-TTT fields as they come and not fill them up.

Julo

clarification.
> 
> In a nutshell all I want to know is this:  Is it legal for an 
> initiator to set the LUN field in the Data-Out PDU based on what it 
> knows the LUN to be, or MUST the initiator copy the contents of the 
> LUN field from the received R2T into the Data Out. 
> 
> initiator sends a write command to a target.  The initiator receives 
> an R2T and starts sending multiple Data-Out PDUs.   The initiator 
> receives 3 more R2Ts but cannot start sending Data-Out PDUs 
> immediately due to outbound resource limitations.   The initiator must
> now store off each R2T request so that it can honor them when 
> resources become available ? otherwise the initiator will need to halt
> receive processing on the connection.   The initiator will probably 
> need to store the Target Transfer Tag, Buffer Offset, and Desired Data
> Transfer Length for each R2T.   Does the initiator need to store the 
> LUN from each R2T as well?  Or can it just fill in the LUN in the Data
> Out PDUs based on knowing what LUN the command was sent to in the first 
place? 
> for a  target-wide unique TTT and enable distributed targets that do 
> not require coordination.  The reason LUN was chosen to tag the R2T is
> that it may simplify routing of the data to the appropriate destination. 

> But since it is called LUN some zealous initiator may check (although 
> it is not mandated) the LUN validity versus a list obtained otherwise 
> - so I would not go for a very liberal interpretation. 
> 
> Julo 

> the actual LUN number specified by the SCSI write?   Since the field 
> is ?only used by the target? I assume this text means that the target 
> may place anything it wants in the LUN field of the R2T and have it 
> echoed back by the initiator.

---

From: Paul Koning <[email-masked]>
Date: Fri, 4 Jan 2008 09:53:59 -0500

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

 Julian> Bill, This is left to the implementer. I would argue that a
 Julian> "liberal" initiator should store the LUN-TTT fields as they
 Julian> come and not fill them up.

That doesn't sound right to me.

Something can only be left to the implementer if any of the allowed
choices interoperate.  And that is not the case here.

If the target treats the LUN field as an additional identifier along
with the TTT, NOT necessarily the same as the LUN number used in the
original I/O request -- which is what section 10.8.5 clearly permits
-- then the only interoperable initiator behavior is to copy the TTT
AND LUN from the R2T to the Data Out message.  If it uses the original
request's LUN instead, it won't interoperate with a target that picks
its own value for the R2T.

So there are two possible answers:

1. A target can put anything it wants in the R2T LUN field, and the
   initiator must use that value from the R2T in its Data Out, or

2. A target must use the original request LUN in the R2T, and the
   initiator can either copy the LUN field from the R2T, or use the
   LUN it used in the request (since they are the same) when building
   its Data Out.

It seems pretty clear to me that the current spec answer is #1.  And
the underlying problem is that the field was called "LUN" rather than
"64 bit cookie" or something like that.

 >> initiator to set the LUN field in the Data-Out PDU based on what
 >> it knows the LUN to be, or MUST the initiator copy the contents of
 >> the LUN field from the received R2T into the Data Out.
 >> 
 >> initiator sends a write command to a target.  The initiator
 >> receives an R2T and starts sending multiple Data-Out PDUs.  The
 >> initiator receives 3 more R2Ts but cannot start sending Data-Out
 >> PDUs immediately due to outbound resource limitations.  The
 >> initiator must now store off each R2T request so that it can honor
 >> them when resources become available ? otherwise the initiator
 >> will need to halt receive processing on the connection.  The
 >> initiator will probably need to store the Target Transfer Tag,
 >> Buffer Offset, and Desired Data Transfer Length for each R2T.
 >> Does the initiator need to store the LUN from each R2T as well?
 >> Or can it just fill in the LUN in the Data Out PDUs based on
 >> knowing what LUN the command was sent to in the first
 >> place?

---

From: [email-masked]
Date: Fri, 4 Jan 2008 10:21:26 -0500

Paul, 

Your comments make sense to me.   The initiator  *should* copy the lun 
over from the R2T.    From a practical standpoint I don't think that  a 
target should rely on the initiator copying that data, since the field is, 
in fact, called "LUN" in the data out message. 

Further, I'm not sure that 10.7.4 is clear on this point:  

"If the Target Transfer Tag is
   provided, then the LUN field MUST hold a valid value and be
   consistent with whatever was specified with the command;" 

One could argue that 'command' is generally used in the context of a SCSI 
command, not an R2T.  To reiterate - It's reasonable to say that an 
initiator should copy the data, but I don't think that a target can depend 
on that behavior.

regards,

david

David J Cuddihy
Principal Engineer
ATTO Technology, Inc.

www.attotech.com
Power Behind the Storage

---

From: [email-masked]
Date: Fri, 4 Jan 2008 12:44:10 -0500

Sounds like whatever the intent of the field was that the spec might be
somewhat ambiguous.   I'll err on the side of caution and make sure the
LUN field is copied from the R2T into the Data-Outs.   Personally in
neither our initiator or target implementations do I even look at that
LUN field in the R2T or Data-Out since the ITT and TTT are sufficient
for tracking the IO.  However I can conceed that some target
implementations may benefit from having the LUN field in the Data-Out.

Bill

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 04, 2008 10:21 AM
To: Paul Koning
Cc: [email-masked]; [email-masked]; Sears, Bill
Subject: RE: [Ips] LUN field in R2T

Paul, 

Your comments make sense to me.   The initiator  *should* copy the lun
over from the R2T.    From a practical standpoint I don't think that  a
target should rely on the initiator copying that data, since the field
is, in fact, called "LUN" in the data out message. 

One could argue that 'command' is generally used in the context of a
SCSI command, not an R2T.  To reiterate - It's reasonable to say that an
initiator should copy the data, but I don't think that a target can
depend on that behavior. 

regards, 

david 

say that the

David J Cuddihy
Principal Engineer
ATTO Technology, Inc.

www.attotech.com <http://www.attotech.com/> 
Power Behind the Storage

---

From: Paul Koning <[email-masked]>
Date: Fri, 4 Jan 2008 12:48:17 -0500

>>>>> "Sears" == Sears Bill <[email-masked]> writes:

 Sears> Sounds like whatever the intent of the field was that the spec
 Sears> might be somewhat ambiguous.  I'll err on the side of caution
 Sears> and make sure the LUN field is copied from the R2T into the
 Sears> Data-Outs.  Personally in neither our initiator or target
 Sears> implementations do I even look at that LUN field in the R2T or
 Sears> Data-Out since the ITT and TTT are sufficient for tracking the
 Sears> IO.  However I can conceed that some target implementations
 Sears> may benefit from having the LUN field in the Data-Out.

 >> "If the Target Transfer Tag is provided, then the LUN field
 >> MUST hold a valid value and be consistent with whatever was
 >> specified with the command;"

 >> One could argue that 'command' is generally used in the
 >> context of a SCSI command, not an R2T.  To reiterate - It's
 >> reasonable to say that an initiator should copy the data, but
 >> I don't think that a target can depend on that behavior.

It sure looks like the spec is contradictory.  So the safe
implementation approach would be:

1. In the initiator, copy LUN from R2T to Data Out, without looking at
   it.

2. In the target, copy LUN from the request to R2T (don't make up your
   own value).

       paul

---

From: Julian Satran <[email-masked]>
Date: Sat, 5 Jan 2008 22:20:16 +0530

Paul,

You are right that the current spec "favors" 1. However it does not forbid 
a "zealous" initiator to check the validity of the LUN.
If we would have gone as far as naming it a cookie we would have had to 
face an interminable discussion about what where the "legal" cookie 
values.
LUN seemed a good enough option fora target that segregates resources 
based on LU.

Julo

Paul Koning <[email-masked]> 
01/04/08 08:23 PM

To
Julian Satran/Haifa/IBM@IBMIL
cc
[email-masked], [email-masked]
Subject
RE: [Ips] LUN field in R2T