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

[julian_satran@il.ibm.com]

That is taking a narrow view on the capabilities of implementers and
protocol analyzer designers.
Another viewpoint is have a minimalist design - do no specify what you
don't have to!

Julo

Santosh Rao <santoshr@cup.hp.com> on 11/01/2001 09:20:20

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   venkat@rhapsodynetworks.com (Venkat Rangan)
cc:   dotis@sanlight.net (Douglas Otis), matt_wakeley@agilent.com (Matt
      Wakeley), ips@ece.cmu.edu (IPS Reflector)
Subject:  Re: iSCSI : On the subject of R2T and Task Tags.





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


>
> 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: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]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,
>
> 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
>
> > Pierre Labat wrote:
> >
> > > 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.
> >
> > 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.
> >
> >
> > >
> > > Regards,
> > >
> > > Pierre
> > >
> > > >
> > > >
> > -Matt Wakeley
> > Agilent Technologies
> >
>
>
>


--
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
#################################