RE: FCIP: Intent of standard in 6.6.2.2

[Sudhir Srinivasan <SudhirS@trebia.com>]

See comment embedded below...

> -----Original Message-----
> From: Robert Snively [mailto:rsnively@Brocade.COM]
> Sent: Friday, September 07, 2001 1:04 PM
> To: 'Barry Reinhold'; ISCSI
> Subject: RE: FCIP: Intent of standard in 6.6.2.2
> 
> 
> Barry,
> 
> The text is, I believe, clear in specifying the authors' intent.
> 
> The text says:
> 
>   Verification SHALL be accomplished by performing the 
> following tests:
> 
>   a) Length field validation -- 63 < (Length * 4) < 2177 (f above);
>   b) Comparison of Length field to its ones complement (f above); and
>   c) At least 6 other of the 22 distinct tests listed above.
> 
>   Errors in FCIP Frame headers SHOULD be considered carefully, since
>   some may be synchronization errors. For example, any failure of the
>   Length field tests described above SHALL be handled as a
>   synchronization error. Errors in FCIP Frames detected by the FCIP_DE
>   that affect synchronization with the Encapsulated Frame Receiver
>   Portal byte stream SHALL be handled as defined by section 6.6.2.3.
> 
> It is clear from this that, if the length field goes bad, you
> absolutely cannot determine where the next frame is and 
> synchronization
> is lost.  6.6.2.3 tells you the requirements for recovering
> synchronization or closing the TCP connection.  Annex A gives
> you one example of a recovery algorithm meeting those requirements.
> Others are possible.

Bob,

I think Barry's point is that as worded currently,
verification __of synchronization__ SHALL fail if test 
(c) fails - i.e. length tests must pass and at least
6 other tests must pass. The problem is that only
some tests imply synch loss and the other tests 
simply indicate a bad frame, and so this is ambiguous.
I will try to come up with a different wording that
matches the intent you described (which is intuitive).

- Sudhir


> 
> The other fields that are tested give you confidence that everything
> is still working right and reduce the probability of falsely 
> indicating that a bad frame is good to infinitesimal values.  
> Numbers for passing a bad frame for good once every million years 
> on a worst case link are considered infinitesimal.  The selection
> of which of these tests to use depends on the implementation and
> architecture of the supporting firmware and hardware.  Some tests
> may be impossible on some types of hardware.  While some
> of these tests may mean that the frame needs to be discarded,
> you SHOULD consider in a vendor specific manner (that does not
> change interoperability) whether or not synchronization actually
> failed. As an example, if the length is valid but the EOF and
> CRC of the frame fail, and the header of the next frame fails some
> of its tests, it is likely that you have lost synchronization.
> However, if the length is valid, the EOF and CRC are valid, but
> the SOF is invalid, you need to discard the frame because you
> cannot define its class of service, but you have probably not 
> lost synchronization.
> 
> It really doesn't matter too much which set of tests you use,
> since they have the same effect.  Bad frames will disappear
> from the link and be retried by ULP mechanisms.  Loss of
> synchronization will be recovered after several frame losses or
> cause the connection to close, depending on how lucky you are
> and how lazy your implementation is.
> 
> Would you suggest any wording changes to reflect that
> meaning?
> 
> Bob
> 
> 
> > -----Original Message-----
> > From: Barry Reinhold [mailto:bbrtrebia@mediaone.net]
> > Sent: Thursday, September 06, 2001 11:23 AM
> > To: ISCSI
> > Subject: FCIP: Intent of standard in 6.6.2.2
> > 
> > 
> > I would like to ensure that I am understanding the intent of 
> > the standard
> > correctly relative to clause 6.6.2.2 (draft 05).
> > 
> > Under the verification SHALL be accomplished....
> > 
> > item C "At least 6 other of the 21 distinct tests listed above."
> > 
> > This means that there SHALL be six other fields tested and 
> > that if any one
> > of them fail then sync. in the TCP stream shall not be 
> > considered acquired.
> > It also means that a frame with 15 fields in error could pass the
> > verification test of some device and that device would still 
> > be consider
> > compliant. Anyone reading this differently?
>