Subject: RE: iSCSI: Reliability of markers (was Re: R2TDataSN and other re covery mechanisms)

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 6 Mar 2001 18:49:10 -0700

Venkat,

> > 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.
> 
> You point out one of the disadvantages of the current marker
> approach.

Not sure what you mean "current marker approach"?  The appendix in iSCSI
05.txt lists two approaches, clearly the second marker approach (fixed
intervals) doesn't suffer from this disadvantage.  In any case, a marker
scheme would be roughly between the iSCSI layer and the TCP layer, so it's
not appropriate to include in the iSCSI header digest.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked]

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 6 Mar 2001 18:59:41 -0700

> Not sure what you mean "current marker approach"?  The 
> appendix in iSCSI 05.txt lists two approaches, clearly the 
> second marker approach (fixed intervals) doesn't suffer from 
> this disadvantage.  In any case, a marker scheme would be 
> roughly between the iSCSI layer and the TCP layer, so it's 

Oops, I again re-read appendix C, it appears to have changed from my
original understanding of "markers at fixed intervals" and as specified it
would suffer from the same undetected corruption if not protected.  However,
this approach would not suffer greatly from unprotected marker information,
since an invalid marker could just cause an implementation to skip ahead to
the next marker and statistically, one should eventually be right ;-)

Cheers,
Marj