Subject: RE: [Tsvwg] Another view of the SCTP error check problem

From: Robert Snively <[email-masked]>
Date: Mon, 2 Jul 2001 09:29:26 -0700

Doug,

I would like to address a few misapprehensions in your note.

Higher level protocols like FCIP never synchronize on 
known corrupt data.  Both TCP and
SCTP do not deliver data that is known to be corrupt, they
retry until either an error slips by, the connection is 
closed, or the data is correct, so there is no known corrupt 
data to synchronize upon.

CRC based headers for higher level data (FCIP, etc.) 
have no effect on synchronization or restoration.
If anything, they are an inconvenience compared with redundancy
checks, since search for a new header cannot begin until the
entire header has been buffered and the CRC has been verified.

If you would kindly review FCIP revision 3, you will find that
the dropping of all outstanding frames only occurs if 
no FCIP resynchronization is attempted or if the TCP or SCTP 
connection fails.  The only frames that are dropped are those
that were delivered in error by the TCP or SCTP transport and
those that cannot be proved valid during the FCIP resynchronization
period.

FCIP frankly does not trust the transports and goes to great
lengths to verify that each encapsulated frame is valid
during the de-encapsulation process, using header redundancy,
known encapsulation formats, data CRC, and FC format information.  
Our preliminary numbers show that the delivery of 
frames with an undetected FC CRC failure will occur on the order 
of once every 100 years at 10 Gbits.  The probability of such
a frame being accepted in an end-to-end environment is reduced
by the FC header verification, including S_ID/D_ID, OX_ID/RX_ID,
Sequence Count, and Sequence ID by another huge factor which
I have not yet bothered to calculate, but is on the order of
2**96.  The subsequent probability of actually using that frame
because it contains valid information is vanishingly small.

As I have continually repeated, enterprise storage environments
will demand performance values that will
encourage network grooming, which will drop the undetected bad
frame delivery numbers by several more orders of magnitude.

I do not know what problem you are describing, so I cannot know
what its impact will be.  I do know that FCIP on TCP will provide
reliability appropriate to its enterprise storage environment.
I also know that TCP does not use CRC.

Bob Snively                        e-mail:    [email-masked]
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110

>  -----Original Message-----
>  From: Douglas Otis [mailto:[email-masked]]
>  Subject: RE: [Tsvwg] Another view of the SCTP error check problem
>  
>  
>  David,
>  
>  Unless there is some method of restoring synchronization, 
>  the recovery
>  becomes more than just a dropped FCIP encapsulated frame if 
>  synchronizing on
>  known corrupt data.  FCIP does not use CRC based headers to allow
>  restoration that may be required many times a day and thus 
>  cause the loss of
>  state between connections and the subsequent dropping of all 
>  potentially
>  outstanding frames.  Considering the level of impact this 
>  problem could
>  exhibit together with overstating the level of protection 
>  afford by the
>  summation, albeit small, only furthers the potential 
>  difficulty, and greatly
>  overlooks the benefits offered by the transport being robust.
>  
>  Doug
>  

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 2 Jul 2001 17:55:51 -0700

Bob,

> data to synchronize upon.

In the case of TCP as example, there will be frequent occurrences of
undetected errors.  The format information relied upon to detect these
events is then used to resynchronize to get past known (as a result of
parsing and not transport detection) bad data.  As the transport has failed
to detect these errors, there is no subsequent retry that will obtain
corrected data.  There is little to prevent false synchronization happening
within a trace log as example.

FCIP Pg 14
   "7)  In the absence of errors, the de-encapsulated frame SHALL be
       passed to the FC Transmitter Portal for delivery to the FC Entity.
Pg 16
   Synchronization of the FCIP_DE to the FCIP Frames in the data stream
   entering the Encapsulated Frame Receiver Portal is maintained using
   the FC Frame Encapsulation header's frame length field to determine
   where in the data stream the next FC Encapsulation header is
   located. Synchronization SHALL be verified by checking the validity
   and positioning of any combination of the following FC Frame
   Encapsulation information:

Pg 17
6.6.2.4 Synchronization Failures

   If an FCIP_DE determines that it cannot find the next FCIP header in
   the byte stream entering through the Encapsulated Frame Receiver
   Portal, the FCIP_DE SHALL either:

   a)  close the TCP connection [9] [11];
   b)  recover synchronization by searching the bytes delivered by the
       Encapsulated Frame Receiver Portal for a valid FCIP Frame header
       having the correct properties, and discarding bytes delivered by
       the Encapsulated Frame Receiver Portal until a valid FCIP Frame
       header is found; or
   c)  attempt to recover synchronization as described in b) and if
       synchronization cannot be recovered close the TCP connection as
       described in a)."

Timeless frames sitting dormant within the data can occur as a result of b.

FC Encapsulation Pg 5:
   "When the sending time is unknown, the Time Stamp
   [integer] and Time Stamp [fraction] words SHALL contain zero."

There is little that would prevent such a stray frame from entering the
system inadvertently.

> entire header has been buffered and the CRC has been verified.

Confirmation can occur following the header ID search.  With the lack of a
validation and lax restrictions on the time field there is little benefit
from CRC as well.  I think most would be concerned about the possible
inadvertent synchronization within a data block still possible with FCIP
revision 3.

> known encapsulation formats, data CRC, and FC format information

There is nothing that prevents valid formats being contained within data.

> of once every 100 years at 10 Gbits.

That figure appears very optimistic.

> The probability of such

Some of this parsing may not provide protection depending on the type of
command and a trace may include the desired values as well.

> frame delivery numbers by several more orders of magnitude.

You are still depending on the FC CRC to ultimately detect errors.

> I also know that TCP does not use CRC.

The concern was from attempts to resynchronize on known bad data while
depending on parsing to detect synchronization.  It would appear easy for
that to go wrong as you should not rely on the content of the data to appear
invalid.  The only sure way to handle this event would be to drop
connections with many frames getting dropped.

Doug

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 9 Jul 2001 14:43:09 +0100 (BST)

On Mon, 2 Jul 2001, Robert Snively wrote:

> will demand performance values that will encourage network
> grooming, which will drop the undetected bad frame delivery
> numbers by several more orders of magnitude.

Build weak endpoint protocols and force people to overengineer their
networks to compensate?

And how do you measure undetected bad frame delivery?

thanks,

L.

taking this with a grain of Saltzer - end2end.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>