RE: R2TDataSN and other recovery mechanisms

["Somesh Gupta" <someshg@yahoo.com>]

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