Re: iSCSI: Header Digest Failure (was R2TDataSN)

[julian_satran@il.ibm.com]

I understood that. But markers are meant to solve this too aren't they?

Julo

Matt Wakeley <matt_wakeley@agilent.com> on 08/03/2001 01:54:10

Please respond to Matt Wakeley <matt_wakeley@agilent.com>

To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: Header Digest Failure (was R2TDataSN)




Julian,

What Somesh is talking about has nothing to do with R2T specifically.  His
point is, the length field in the PDU header determines how long *this* PDU
is, and where to find the *next* PDU.  If *this* PDU fails its header
digest
check, you cannot trust the length field, therefore, you cannot know where
the
*next* PDU is in the byte stream.

Given that, is seems like whenever there is a header digest error, you have
no
choice but to terminate the TCP connection and start a new one.

-Matt Wakeley
Agilent Technologies


Somesh Gupta wrote:
>
> Julian,
>
> How do I know it is an R2T if the header digest failed?
> I am sorry if I am missing something very obvious here.
>
> Let us say that a header digest failed. What information
> in the header am I able to trust at this point? I don't
> know if it is an R2T or not. I don't know if the length
> is ok or not.
>
> Thanks,
> Somesh
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > julian_satran@il.ibm.com
> > Sent: Tuesday, March 06, 2001 4:01 PM
> > To: ips@ece.cmu.edu
> > Subject: RE: R2TDataSN
> >
> >
> >
> >
> > Somesh,
> >
> >  I am still lost. R2T is fixed length and you know that you have a bad
> > digest after reading it.
> > No length involved.   ???
> >
> > Julo
> >
> > "Somesh Gupta" <someshg@yahoo.com> on 07/03/2001 00:26:10
> >
> > Please respond to someshg@yahoo.com
> >
> > To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > cc:
> > Subject:  RE: R2TDataSN
> >
> >
> >
> >
> > Julian,
> >
> > > -----Original Message-----
> > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf
Of
> > > julian_satran@il.ibm.com
> > > Sent: Tuesday, March 06, 2001 9:31 AM
> > > To: ips@ece.cmu.edu
> > > Subject: RE: R2TDataSN
> > >
> > >
> > >
> > >
> > > Somesh,
> > >
> > > You've lost me. I do not propose that you look at the bad R2tT but to
> > find
> > > that you have missed one
> > > by looking at the next.
> >
> > Since iSCSI PDUs define how long they are, you have to look at
> > one PDU to determine where the next PDU is. (unless ofcourse
> > the sync and steering layer is doing the work - see my exchange
> > with Venkat on that).
> >
> > On the long transfer etc., I was not sure what scenarios
> > an R2TDataSN was providing recovery from. Since you clarified
> > that it is to recover from a header digest error, we can
> > focus on that scenario.
> >
> >
> > This interesting for long transfers that have
> > > several outstanding R2Ts.
> > > What is speculative here? There was never a consensus that there
> > > will be no
> > > more than one outstanding R2T.
> > >
> > > Regards,
> > > Julo
> > >
> > > "Somesh Gupta" <someshg@yahoo.com> on 06/03/2001 17:23:04
> > >
> > > Please respond to someshg@yahoo.com
> > >
> > > To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > > cc:
> > > Subject:  RE: R2TDataSN
> > >
> > >
> > >
> > >
> > > I beg to disagree. If an R2T PDU (header) has bad digest, or any
other
> > > header has a bad digest - since you always need the PDU length from
> > > the header, there is some uncertainty associated with further
> > processing.
> > >
> > > Are you proposing that the processing machine go into a "speculative"
> > > mode where the processing of the next PDU determines whether we were
> > > successfuly able to skip a bad PDU header? When there is a data
digest
> > > error, further stream parsing is deterministic. But not when the PDU
> > > header digest error.
> > >
> > > Also the consensus (in my interpretation) was on applications
> > > not transfering very large amounts of data using a single command or
> > > read/write PDU.
> > >
> > > > -----Original Message-----
> > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf
Of
> > > > julian_satran@il.ibm.com
> > > > Sent: Monday, March 05, 2001 5:41 PM
> > > > To: ips@ece.cmu.edu
> > > > Subject: Re: R2TDataSN
> > > >
> > > >
> > > >
> > > >
> > > > Somesh,
> > > >
> > > > 1.The only consensus I heard is not to transfer a large amount of
> > > > data with
> > > > one PDU.
> > > >
> > > > 2.With DatasN and Sack we dont need any data in a bad header.
> > > >
> > > > 3. If an R2T is lost (received at initiator with bad digest) - the
> > > > initiator will know that from
> > > > the next R2T if the target has several outstanding - very likely at
> > long
> > > > distances - and will not have to way for a timeout.   Other uses
are
> > > > marginal.  Basically it is "part of a command execution" and we can
> > > > painless recover
> > > > from failures for this case too.
> > > >
> > > > Regards,
> > > > Julo
> > > >
> > > > "Somesh Gupta" <someshg@yahoo.com> on 05/03/2001 20:40:06
> > > >
> > > > Please respond to someshg@yahoo.com
> > > >
> > > > To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > > > cc:
> > > > Subject:  R2TDataSN
> > > >
> > > >
> > > >
> > > >
> > > > > R2TDataSN
> > > > > ----------
> > > > > Sec 6.7.1 has some new content on how to handle lost R2Ts using
> > > > > SACKs.  But I noticed that the SACK request (Sec 2.16) has not
> > > > > changed to indicate whether the DataSN is a R2T DataSN or just
> > > > > a Read PDU DataSN (D bit)
> > > > > So do we demux on the read/write operation type?
> > > > > And how does this affect PDU loss in bidirectional commands ?
> > > > > +++ SACK is ascking for data (DataSN) the target knows
> > > > >
> > > >
> > > > Julian,
> > > >
> > > > Regarding the R2TDataSN, I have a comments and a
> > > > question.
> > > >
> > > > I think that when a PDU header fails a CRC/checksum check etc,
> > > > it is a problem to depend on any information in the header
(including
> > > > length fields), thereby making any further processing on
> > > > the connection unreliable.
> > > >
> > > > What scenarios do you envision where the R2TDataSN is useful.
> > > > IN Orlando I think there was clear consensus that application
> > > > do not try to transfer very large amounts of data using a
> > > > single command.
> > > >
> > > > Thanks,
> > > > Somesh
> > > >
> >
> > Thanks,
> > Somesh Gupta
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> >
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com