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

[Santosh Rao <santoshr@cup.hp.com>]

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
#################################