Subject: Re: iSCSI : On the subject of R2T and Task Tags.

From: Raghavendra Rao <[email-masked]>
Date: Tue, 9 Jan 2001 14:18:49 -0500 (GMT)

> Since a READ Data PDU has no Target Task Tag, is it the expectation that
> iSCSI targets should perform a lookup on the Initiator Task Tag to obtain
> their per-task data structure ? This is a performance penalty, if so.
> 

For a SCSI READ command, I don't think it'll be really useful to have a target
task tag.

> Again, with WRITE Data PDUs there is no target assigned
> per-task tag. While one could argue about vertically encoding the Target

There is - this is done during R2T time and every solicited data PDU
from the initiator goes out with this tag.

BTW, SAM-2 rev 14 has 64 bit task tags; How are we handling situations
like these ?

-JP

---

From: Santosh Rao <[email-masked]>
Date: Tue, 09 Jan 2001 14:50:30 -0800

> from the initiator goes out with this tag.

The "Target Transfer Tag" that you are referring to is per R2T and not per task.
There is no per-task identifier that can be used by the targets to track the
task. They will either have to :

a) use the Initiator Task Tag

or

b) resort to some form of vertical encoding of the Target Task Tag (a per-task
target id) into the Target Transfer Tag (the PDU defined per-R2T target id).

(a) has perofrmance impacts.
(b) is an ugly implementation-specific kludge and also reduces the Target Task
Tag space due to the vertical encoding of 2 fields into the 32-bit space.

Thanks,
Santosh

---

From: Matt Wakeley <[email-masked]>
Date: Tue, 09 Jan 2001 15:42:50 -0800

The task tags in iSCSI should work the same as they do in FCP:

The initiator supplies a initiator task tag per task that it uses to associate
any received messages from the target to that task. [a "undefined" initiator
task tag should have a value of 0xffffffff since a value of zero is a valid
number for a table look up ].

The target supplies a target task tag per task that it sends to the initiator
where a response from the initiator is expected.  The target uses the target
task tag to associate any solicited received messages from the initiator
(other than the initial command) to that task.

For SCSI READ commands, there is no need to specifiy a target task tag.
Typically in FCP today, the targets to NOT assign target task tags (RX_IDs in
FC terms) for READs.

For SCSI WRITE commands, the target MAY assign a target task tag to the I/O
that it uses when sending R2Ts to the initiator.  The initiator must then echo
that target task tag in replies it sends to the target.  I strongly object to
the words in section 2.16 "All outstanding R2T should have different Target
Transfer Tags".  This specification should not dictate to the target how it
chooses or uses the Target Task Tags.

-Matt Wakeley
Agilent Technologies

---

From: Santosh Rao <[email-masked]>
Date: Tue, 09 Jan 2001 19:27:39 -0800

> chooses or uses the Target Task Tags.

I agree with Matt on the semantics of "Target Task Tag" for WRITE PDUs and would
also like to request a "Target Task Tag" per task for WRITE PDUs.

In addition, since multiple R2Ts can be outstanding, an additional qualifier is
required to track the R2T (Target R2T Tag) along the lines of a (RX_ID + SEQ_ID)
that Fibre Channel uses.

Thanks,
Santosh

---

From: Pierre Labat <[email-masked]>
Date: Tue, 09 Jan 2001 22:41:52 -0800

> chooses or uses the Target Task Tags.

Matt,

I agree that the draft must not impose to the target to have a different tag
for each R2T (it is up to the target implementation to decide).  I disagree
to impose a unique target tag for the whole IO.  It imposes the target to do
score boarding
to know when all the data have been received. Letting the possiblility to the
target
to have one tag per R2T (or add a subtag identifying the R2T as proposed Santosh)

allows the target to dispense with the score boarding. The target knows that all
the
data has been received when a data PDU with the "F" bit set has been received
for each R2T.

Regards,

Pierre

---

From: Matt Wakeley <[email-masked]>
Date: Wed, 10 Jan 2001 12:50:16 -0800

> required to track the R2T (Target R2T Tag) along the lines of a (RX_ID + SEQ_ID)

I don't think an additional qualifier is needed.  For what purpose?

The target just sends out all the R2Ts, and counts all the bytes coming back
(remember - TCP guarantees to deliver each byte only once!).  Also remember,
the iSCSI spec mandates that the initiator send only what was requested in the
R2T... nothing more.

-Matt Wakeley
Agilent Technologies

---

From: Matt Wakeley <[email-masked]>
Date: Wed, 10 Jan 2001 12:52:21 -0800

> data has been received when a data PDU with the "F" bit set has been received

There is no need to do scoreboarding.  Just count the number of bytes
received.  If they all add up, then you've received all the data.  I for one
would not rely on a PDU with the "F" bit set.  I would want to cross check it
with the correct number of bytes.

-Matt Wakeley
Agilent Technologies

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 10 Jan 2001 17:27:27 -0800

Matt,

With independent error checking requiring an additional level of error
handling requesting repeated reads, there could be old responses combined
with the retry from failed data digests. (If requesting overlapped reads are
prohibited, retry is an exception.) Without some means of identifying which
retry phase data is associated, a complete set would be difficult to
confirm.  As order of each data portion is not mandated and these transfers
themselves may overlap, byte counts can not reveal completion.  Should does
not mean 'must.'

Doug

---

From: Pierre Labat <[email-masked]>
Date: Wed, 10 Jan 2001 18:24:40 -0800

Matt,

To have differents tag or (tag + subtag) one for each R2T allows the target to find
directly the buffer address. For example  using the tag as an index in a table. If
not, the target has
to go through a list of R2T control structures  and for each one compare the offset
with
with the interval recorded in the R2T structure, in order to find the right buffer.
As it doesn't hurt on the initiator side, why not to do it?

In fact an R2T and the data related are as an exchange. Hence it is natural
to have one identifier/exchange.
Of course if the target want to use the same it could.

Regards,

Pierre

---

From: "Venkat Rangan" <[email-masked]>
Date: Wed, 10 Jan 2001 20:17:02 -0800

Doug,

The draft make should not make any statements about how a target chooses to
assign Target Task Tags. Some may choose to assign it per R2T, others may
choose to assign it per task, based on how they choose to implement the
target. Since the initiator is required to reflect it, I do not believe
there are any interoperability issues. If an implementation wishes to do a
Task-SubTask breakdown, they can choose to partition the 32 bits into
portions that can be used for identifying resources within the target.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Douglas Otis
Sent: Wednesday, January 10, 2001 5:27 PM
To: Matt Wakeley; IPS Reflector
Subject: RE: iSCSI : On the subject of R2T and Task Tags.

Matt,

Doug

---

From: Santosh Rao <[email-masked]>
Date: Wed, 10 Jan 2001 23:20:20 -0800 (PST)

The draft must provide for seperate fields to track the task and the R2T
along the lines of RX_ID and SEQ_ID in Fibre Channel. Implementations are
free to use them as they please and must use 0xFFFFFFFF as their un-used
values in these fields. 

The advantage of defining the fields explicitly in the header as opposed
to allowing targets to vertically encode a portion of the tag field for
tracking the R2T is that these standard fields are interpret-able 
by iSCSI Analyzers and will make debugging and tracking the 
sequence of the I/O easier than implementation specific 
vertical encoding into a single field. 

Merging the 2 into a single field is akin to attempting to merge the 
OX_ID, SEQ_ID and SEQ_CNT fields of FC into a single field and 
allowing implementation specific vertical encoding. Standard defined
fields make for easier introp verification and debugging.

- Santosh

-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 11 Jan 2001 11:02:23 -0800

Venkat,

You misunderstood my comment.  Matt had indicated a simple solution of
counting bytes.  As you indicate, the target tag is uncertain.  Assumptions
about data not overlapping is also incorrect and data overlays may not be
sent in sequence.  All of this adds to difficulty in confirming completion
before returning to the application.

Doug

---

From: Matt Wakeley <[email-masked]>
Date: Mon, 15 Jan 2001 20:42:00 -0800

> Of course if the target want to use the same it could.

You already have everything you need.  The target_task_tag references the
context, and the Offset field references where in the buffer(s) to place the
data.

-Matt

---

From: Matt Wakeley <[email-masked]>
Date: Mon, 15 Jan 2001 20:39:04 -0800

> vertical encoding into a single field.

Uh, now that any kind of "out of band" framing is gone, it will be very
difficult to make an analyzer that is capable of syncing up with an iSCSI
session.

-Matt