SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: R2TDataSN and other recovery mechanisms



    
    
    No I am proposing we use markers. Julo
    
    "Somesh Gupta" <someshg@yahoo.com> on 08/03/2001 05:10:24
    
    Please respond to someshg@yahoo.com
    
    To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    cc:
    Subject:  RE: R2TDataSN and other recovery mechanisms
    
    
    
    
    Well it does seem that you are 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?
    
    I think it is time to start another seperate thread on requirement
    for more details and rigorous/perhaps formal description of
    various recovery tools that we have and determine how to
    use them, and identify any possible holes in them.
    
    Somesh
    
    > -----Original Message-----
    > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > julian_satran@il.ibm.com
    > Sent: Wednesday, March 07, 2001 5:21 AM
    > To: ips@ece.cmu.edu
    > Subject: RE: R2TDataSN and other recovery mechanisms
    >
    >
    >
    >
    > Somesh,
    >
    > OK - so what? You will get another digest error (if choose a good digest
    > -:)) and look  for the next marker.
    >
    > Regards,
    > Julo
    >
    > "Somesh Gupta" <someshg@yahoo.com> on 07/03/2001 04:09:31
    >
    > Please respond to someshg@yahoo.com
    >
    > To:   Julian Satran/Haifa/IBM@IBMIL, someshg@yahoo.com
    > cc:
    > Subject:  RE: R2TDataSN and other recovery mechanisms
    >
    >
    >
    >
    > Julian,
    >
    > The point was not about whether the markers were covered
    > by digests. The point is about the fact that errors
    > occured in that range on the TCP stream that were
    > caught (header digest error) - it does seem likely that
    > the marker might have an error too?
    >
    > Somesh
    >
    > > -----Original Message-----
    > > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
    > > Sent: Tuesday, March 06, 2001 3:52 PM
    > > To: someshg@yahoo.com
    > > Subject: RE: R2TDataSN and other recovery mechanisms
    > >
    > >
    > >
    > >
    > > Markers are not covered by digests (they are not supposed to be seen at
    > > digest formation.
    > > The layer model appears in the draft.
    > >
    > > Regards,
    > > Julo
    > >
    > > "Somesh Gupta" <someshg@yahoo.com> on 06/03/2001 20:20:56
    > >
    > > Please respond to someshg@yahoo.com
    > >
    > > To:   "Venkat Rangan" <venkat@rhapsodynetworks.com>, someshg@yahoo.com,
    > >       Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    > > cc:
    > > Subject:  RE: R2TDataSN and other recovery mechanisms
    > >
    > >
    > >
    > >
    > > Venkat,
    > >
    > > You are right but this does put some additional requirements
    > > on the sync and steering layer (assuming we can agree on one
    > > and that it is not optional).
    > >
    > > Consider the marker mechanism as an example. If the marker
    > > falls within the TCP byte stream region which contains the
    > > header, and the header digest fails, then do you trust this
    > > marker or skip to the next marker. Or do we need a sum on the
    > > marker itself.
    > >
    > > We do have various recovery mechanisms in the protocol without
    > > detailed state machines or other documentation to make sure
    > > that the mechanisms are really robust and worth including. And
    > > even more important, that we will have interoperable
    > > implementations that are implemented to the standard (rather
    > > than being compliant with some defacto implementation)
    > >
    > > I am not saying that these tools do not work, and Julian
    > > (and other smart people)may even have worked them out.
    > > However, the proof is not in the document.
    > >
    > > Thanks,
    > > Somesh
    > >
    > > > -----Original Message-----
    > > > From: Venkat Rangan [mailto:venkat@rhapsodynetworks.com]
    > > > Sent: Tuesday, March 06, 2001 10:00 AM
    > > > To: someshg@yahoo.com; julian_satran@il.ibm.com; ips@ece.cmu.edu
    > > > Subject: RE: R2TDataSN
    > > >
    > > >
    > > > Somesh,
    > > >
    > > > > When there is a data digest error, further stream parsing is
    > > > > deterministic. But not when the PDU header digest error.
    > > >
    > > > Isn't it true that with Synch and Steering layer, you are able to
    > > > skip past
    > > > PDUs with header-digest errors and reach a point where you can begin
    > > > deterministically processing the stream? (assuming that the
    > > > headers used for
    > > > Synch and Steering are in-tact).
    > > >
    > > > Of course, in the event that this option is "negotiated out" you
    > > > don't have
    > > > this ability.
    > > >
    > > > 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
    > > > Somesh Gupta
    > > > Sent: Tuesday, March 06, 2001 7:23 AM
    > > > To: julian_satran@il.ibm.com; ips@ece.cmu.edu
    > > > 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
    > > >
    > >
    > >
    > > _________________________________________________________
    > > 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
    >
    >
    >
    
    
    _________________________________________________________
    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