Subject: FCIP: Intent of standard in 6.6.2.2

From: "Barry Reinhold" <[email-masked]>
Date: Thu, 6 Sep 2001 14:23:14 -0400

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?

Barry Reinhold
Principal Architect
Trebia Networks
[email-masked]
603-868-5144/603-659-0885/978-929-0830 x138

---

From: Sudhir Srinivasan <[email-masked]>
Date: Fri, 7 Sep 2001 01:05:15 -0400

Barry,

I think the standard is not worded precisely enough here.
For instance, the para right after the text you highlighted
seems to make it ambiguous - it can be interpreted as saying
that really only length field test failures are sync errors 
and the other tests are not necessarily so (which makes sense
to me). I think this should be clarified with the authors.

- Sudhir

   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.4.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Trebia Networks, Inc.    [email-masked]
978-929-0830 x139        www.trebia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> -----Original Message-----
> From: Barry Reinhold [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 2:23 PM
> To: ISCSI
> Subject: FCIP: Intent of standard in 6.6.2.2
> 
>

---

From: Robert Snively <[email-masked]>
Date: Fri, 7 Sep 2001 10:04:15 -0700

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.

  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.

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

> Sent: Thursday, September 06, 2001 11:23 AM
> To: ISCSI

---

From: Sudhir Srinivasan <[email-masked]>
Date: Mon, 10 Sep 2001 10:00:51 -0400

See comment embedded below...

> From: Robert Snively [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 1:04 PM
> To: 'Barry Reinhold'; ISCSI
> Subject: RE: FCIP: Intent of standard in 6.6.2.2
> 
> 
> Barry,
> 

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