Subject: RE: R2TDataSN and other recovery mechanisms

From: [email-masked]
Date: Wed, 7 Mar 2001 15:20:46 +0200

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" <[email-masked]> on 07/03/2001 04:09:31

Please respond to [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
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: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 3:52 PM
> To: [email-masked]
> 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" <[email-masked]> on 06/03/2001 20:20:56
>
> Please respond to [email-masked]
>
> To:   "Venkat Rangan" <[email-masked]>, [email-masked],
>       Julian Satran/Haifa/IBM@IBMIL, [email-masked]
> 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:[email-masked]]
> > Sent: Tuesday, March 06, 2001 10:00 AM
> > To: [email-masked]; [email-masked]; [email-masked]
> > 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: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Somesh Gupta
> > Sent: Tuesday, March 06, 2001 7:23 AM
> > To: [email-masked]; [email-masked]
> > 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: [email-masked] [mailto:[email-masked]]On Behalf
Of
> > > [email-masked]
> > > Sent: Monday, March 05, 2001 5:41 PM
> > > To: [email-masked]
> > > 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" <[email-masked]> on 05/03/2001 20:40:06
> > >
> > > Please respond to [email-masked]
> > >
> > > To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
> > > 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

---

From: "Somesh Gupta" <[email-masked]>
Date: Wed, 7 Mar 2001 19:10:24 -0800

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

> Sent: Wednesday, March 07, 2001 5:21 AM
> To: [email-masked]

---

From: "Somesh Gupta" <[email-masked]>
Date: Wed, 7 Mar 2001 19:23:53 -0800

I hope David and Julian will excuse me for using the following
sentences from the Orlando minutes.

-----------  start of quote -------------------------------

- There will be a significant connection recovery write-up,
	including details, procedures and examples added to the draft.

-----------  end of quote ---------------------------------

As an engineer, I believe that we do need detailed and thorough
description of the usage of all the recovery tools in the
protocol. This ensures

1. Determination that there are no holes. Presence of "holes"
   will lead to the mechanisms not being used (but implemented)

   or determine that there are no holes which will lead
   to testing nightmares.

2. Ensure interoperability among implementations

I hope this does not sound like I am asking Julian to do
my work for me. But it is better hashed out and debated
in one place.

If the rest of the working group does feel that the level of
detail in the spec is enough and the rest is an "exercise
for the reader", I will accept that.

Thanks,
Somesh