Subject: RE: [Tsvwg] Re: [rdma] a proposal for a different No-Data-Touch f ramer for TCP

From: "WENDT,JIM (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 13 Feb 2002 11:00:19 -0800

> The other point to note is that you only play the dice at all if
> resegmentation DOES result from an intermediary, since the source will
> only send segments which are known not to fail false-positively.  This
> technique applies equally to Julian's proposal.

And furthermore, in the case of TUF, only when there has been a
drop of a packet contain a TUF header. Since the length field chains to
the next TUF header, the receiver only has to succumb to probability
when it has lost its way. This would seem to reduce the rate of
occurrence somewhat depending on the packet loss rate.

Jim

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

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Thu, 14 Feb 2002 18:35:32 -0700

All,

If you use this as in the TUF proposal, then false positives are only
important when the first re-segmented and therefore non-aligned packets
arrive just as packets have been dropped. Since the stream may have gone
from not being resegmented to being re-segmented because of a path change,
it may not be unusual for re-segmentation to happen at the same time that
packets are arriving out of order or packet drops have occurred.

Currently the text in the ulp frame documenmt says: 
     "A TUF implementation which detects a very low
     incidence of the ULPDU containment property for a sustained
     interval (>> RTT) may assume that a resegmenting intermediary is in
     operation and SHOULD discontinue the use of ULP control information
     found using the ULPDU containment property.  "
but, one could reduce the vulnerability by setting a low threshold for
turning off use of ULP when packets have failed containment and requiring
detection of containment for multiple segments before relying on containment
again.

Both TUF and ESC have about the same false positive probabiliy when testing
a single instance at the start of a segment. TUF requires 64 bits to match
the segment length and the key and ESC requires its 96 bit header to match
one of 2^32 correct headers. Note that including data not in the header (a
shared "secret") in the CRC calculation doesn't change this probability. It
is still matching 2^96 data patterns against 2^32 correct answers. The only
thing a shared secret would help is the case where the ULP also covered 64
bits with the same 32-bit CRC because that would yield a false positive when
time the first 32 bits was the framing pattern.

If data is randomly distributed, then probability of a false-positive when a
resegmenting middle box has destroyed containment is ~5e-20. For comparison,
failure of a 32-bit CRC to detect an error longer than its burst detection
and hamming distance is ~2e-10. 5e-20 is a sufficient protection against
false positives for a rare event. If one was gaining and losing containment
once a second it would still take about 1e12 years to get a false positive
just as one was losing containment. Data is of course not randomly
distributed and it is possible that the key conincides with a pattern that
occurs more frequently in the data stream then it would occur in a random
data stresm. For instance, if a machine at my company chose a key that
happened to coincide with part of the ASCII string for Agilent. But, if one
is only testing the first words of segment to detect containment, one can
tolerate a reasonable degredation below 5e-20 for a false positive.

On the other hand, the NDT proposal implies that its method could be used
even in the absence of containment. I don't think that the protection
against false positives is high enough to be robust in that situation. It
doesn't provide a length field, so when packets are arriving in order, it
will either have to use a ULP specific field to decide where to search for
the next candidate framing header or it will be checking every 4 bytes for a
96 bit match. In the latter case, it is checking 3e7 times per second if
data is arriving at about 1 Gbit/s. At that rate with random data, it takes
about 1e5 years to get a false positive, but degredation due to
non-randomness of data could pull the number much lower.

It is not clear to me that either method is robust enough to use when
containment has been lost because we can't quantify how often the algorithm
will have to search every 4 bytes for the header due to out-of-order
arrival. Having a length field in the header will be more robust because
once a header is found in an exhaustive search, subsequent headers can be
found based on the length field. It is even possible to reduce the false
positive rate by only accepting a header found by exhaustive search if the
location pointed to by the length field also contains a valid header.

Regards,
Pat Thaler

-----Original Message-----
From: WENDT,JIM (HP-Roseville,ex1) [mailto:[email-masked]]
Sent: Wednesday, February 13, 2002 11:00 AM
To: 'Stephen Bailey'; John Hufferd
Cc: [email-masked]
Subject: RE: [Tsvwg] Re: [rdma] a proposal for a different No-Data-Touch
f ramer for TCP

Jim