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

From: Robert Snively <[email-masked]>
Date: Tue, 3 Jul 2001 08:52:53 -0700

>  
>  Bob,
>  
>  > 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.
>  
>  In the case of TCP as example, there will be frequent occurrences of
>  undetected errors.  

My point exactly.  These are unknown corrupt data.  It is for
that reason that the checking processes described in FCIP
are used.

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

My point exactly.  FCIP revision 3 clearly states that
suspect data is discarded and not passed on to FC.

There is little to prevent false 
>  synchronization happening
>  within a trace log as example.
>  

I assume you mean an FC encapsulation of an FC encapsulation.
In fact there is a great deal to prevent false synchronization.
See Annex A.

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

They are not sitting dormant within the data.  The data is
discarded.

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

What inadvertent source would you propose for that frame
that would not result in the frame being discarded?

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

I welcome a detailed analysis of the resynchronization process
proposed in Annex A.  I do not think there are any escapes from
it, but if there are, lets fix them.  Note that there are some
assumptions in this work.  The principal assumption is that
security and authentication practices prevent actively
hijacking the TCP data stream, which of course would not
be detectable by the FCIP_DE.

>  
>  > 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
>  
>  There is nothing that prevents valid formats being contained 
>  within data.

That is absolutely correct.  However, there is a great deal
that prevents them from being falsely considered as valid during
the resynchronization process.

>  
>  > 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.
>  
>  That figure appears very optimistic.

The figure assumes the worst case TCP/IP check sum escape 
numbers from Partridge and Stone's paper, rev'd up to
10 Gbit, and assumes all errors are "massive". 
 
>  
>  > 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.
>  
>  Some of this parsing may not provide protection depending on 
>  the type of
>  command and a trace may include the desired values as well.

Absolutely correct.  However, all data is discarded until
resynchronization has either been successfully achieved or
the algorithm has given up and closed the connection.

>  
>  > 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.
>  
>  You are still depending on the FC CRC to ultimately detect errors.
>  

Of course it is an important additional mechanism.  The nice
thing about it is that it need not be generated or checked in any IP
component, but only as part of the end-to-end FC connection.  It
is above the transport level, but as I have previously said,
FCIP never trusts the transport level completely.

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

You are welcome to implement it that way.  If someone else
implements it the other way, therefore demonstrating improved
performance and reliability, they also have that option.  I do
not see that either is more or less sure than the other, since
FC is used to finding an occasional bad frame and scrapping it.
If the data were totally unstructured, I would agree with you that
we cannot rely on it.  However, the data is totally structured
at two different levels, so that we actually can rely on it.

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

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 3 Jul 2001 13:04:16 -0700

Bob,

David has already responded to this framing recovery issue back in March on
the IPS reflector and I see little that has changed in Annex A to ensure
there is not this problem.

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03736.html

Doug