RE: iSCSI: ITT field in draft 11

["Ranganathan, Deva" <Deva_Ranganathan@adaptec.com>]

Robert,

I agree with you that we need to have a consistent format defined for
efficient 
implementation. As Pat suggests, ITT  needs to,probably, be defined in BHS. 

Thanks

Deva

-----Original Message-----
From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
Sent: Thursday, March 21, 2002 3:19 AM
To: Ranganathan, Deva
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI: ITT field in draft 11


Deva:

I don't think so.  The target action must not be implementation
dependent because then initiators would not be able to
reliably use the value in the ITT field, which is the whole point.

Bob Russell


On Wed, 20 Mar 2002, Ranganathan, Deva wrote:

> Robert,
>
> Is this not implementation related?
>
> -Deva
>
>
> -----Original Message-----
> From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
> Sent: Wednesday, March 20, 2002 5:26 AM
> To: Julian Satran
> Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> Subject: iSCSI: ITT field in draft 11
>
>
> Julian:
>
> One of the changes that came in with draft 11 is that in the
> Asynchronous Message PDU and in the Reject PDU the 4-byte field
> at offset 16 became:
>    16| Reserved -0xffffffff
> whereas previously it had just been Reserved.
>
> I believe the reason for explicitly specifying the value 0xffffffff
> is because this field in all other PDUs is the Initiator Task Tag,
> and for all those other PDUs this value means there is no valid
> Initiator Transfer Tag.  This change now makes it possible for an
> initiator to find the task associated with each incoming PDU before
> looking at the opcode of the PDU.  So far so good.
>
> The problem is that this field cannot be called Reserved due to section
> 9 which says that receivers MUST ignore reserved fields, thus defeating
> the whole purpose of defining a value the initiator can use.
>
> To correct this, the specs for both Asynchronous Message and Reject
> should be changed to explicitly include the Initiator Task Tag field
> and specify in the descriptions of each of those PDUs that this field
> MUST be set to 0xffffffff.
>
> If this is done, then every PDU will contain the Initiator Task Tag field,
> and the description of the BHS in section 9.2.1 can be changed from:
>   16| Initiator Task Tag or Opcode-specific fields
> to
>   16| Initiator Task Tag
> which would clearly show the consistent meaning of this field over all
PDUs.
>
>
> Also, there are two related minor clarifications that should be made:
>
> 1) The 4th paragraph of section 9.16.1 currently says:
>       "For Status SNACK, the Initiator Task Tag is reserved."
>    It would be better if this said explicitly:
>       "For Status SNACK, the Initiator Task Tag MUST be set to the
>       reserved value 0xffffffff."
>
> 2) The last sentence in section 9.5.3 says:
>       "For all the other functions this field is reserved."
>    It would be better if this said explicitly:
>       "For all the other functions this field MUST be set to the
>       reserved value 0xffffffff."
>    (Note that the corresponding sentence in section 9.6.2 already
>    says this.)
>
>
> Thanks,
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>