SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    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. 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
    >
    > _________________________________________________________
    > 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
    
    
    
    
    

    • Follow-Ups:


Home

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