SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: Header Digest Failure (was R2TDataSN)



    What you say is that some method of framing is *required* to perform recovery
    after a header digest failure.  So, is it then to be inferred that framing in
    iSCSI is mandatory?
    
    -Matt Wakeley
    
    
    julian_satran@il.ibm.com wrote:
    > 
    > 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
    


Home

Last updated: Tue Sep 04 01:05:25 2001
6315 messages in chronological order