[Tsvwg] Re: [rdma] a proposal for a different No-Data-Touch framer for TCP

["John Hufferd" <[e-mail]>]

Steph,
How small do you think the segmentation will be, and will they generally be
on a word boundary?  The value I used for 361 or 362 (lets call it the
segmentation-point-number) was based on the possibility that the
segmentation could occur on any word boundary in a normal 1460 byte
payload.  If this segment will never get smaller then say 500 bytes, then
clearly the number will change and the probability will be even lower,  on
the other hand if the segmentation can be on a byte level, the
segmentation-point-number will be larger and the probability of false
positive would be higher.

So some guidance on the techniques of fragmentation and resultant sizes
would be useful.

I had assumed, based on what I thought I read in your document, that as
soon as you detected the Re-Segmentation, you would stop TUFing, since I
thought that the re-segmenting was likely to last for a long time.  Then,
when you thought things had reach a steady state again, you would re-probe
for the PMTU, and use that for your new  Frame Size and begin again.  If I
had that right, then, the shut down would be immediate, and only one False
Positive Event would need to be detected.  In that single event case the
probabilities I calculated would be (approximately) correct.

Now, given a single segmentation, and the other assumptions I used, we were
able to get a probability of a single occurrence.  However, if this
re-segmentation and the resulting needed detection, was to continue for
some period of time, then that would clearly change (raise) the probability
very quickly.



 .
.
 .
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office [phone], Tie: 276-0403,  eFax: [phone]
Home Office [phone], Cell: [phone]
Internet address: [e-mail]


Stephen Bailey <[e-mail]> on 02/11/2002 02:41:26 PM

To:    John Hufferd/San Jose/IBM@IBMUS
cc:    [e-mail], [e-mail]
Subject:    Re: [rdma] a proposal for a different No-Data-Touch framer for
       TCP



John,

Thanks for the exhausting analysis.

As Paul points out, you do not want to scan the received segment to
recover synchronization with either of these techniques, since it's
too risky.  The TUF draft specifically makes this point.  Basically,
you get one event per segment.  However, if you want to be really
pessemistic you could say the stream IS segmented into tiny frames
that almost result in scanning.

The TUF draft also says that the use of a TUF-derived PDU containment
property should be discontinued after repeated failure of PDU
containment.  Given Julian's repeated statements that TUF should be
analyzed against an infinite stream, I can conclude that the draft
does not make this point strongly or clearly enough.

The TUF assumption is that there are two distinct, quasi-stable
scenarios: segmentation is preserved or it is not.  Obviously if
segmentation is not preserved, there's no point in trying to use the
PDU containment property because it will never hold.  If a receiver
detect that the PDU containment property does not hold for longer than
would represent a transient condition like PMTU change, it gives up
and stops using it.

Julian's argument that TUF needs to be analyzed against an infinite
stream is a straw man.  You can pick the threshold at which a TUF
receiver gives up to be any number that makes you comfortable (10e6
packets, 10e4, whatever).

I'm not clear on how your analysis incorporates worst case data
pattern distribution assumptions.  There is a ULP running inside the
framing protocol, and if we assume the ULP is efficient, MOST of the
data IT carries is actually controlled by the user of the ULP.  This
user data can just as well be a `search and destroy' sequence that
tries every `eye catcher' in a well-formed context.  This technique
boils down to a blind search for a 32-bit integer, and there's the
additional probability of hitting any particular element of the blind
search pattern (basically like your ex and ey).  Julian's extra 64
bits (salt & digest) are not doing anything for you in this case.
It's as simple as the probability of the resegmented stream hitting
the correct 32-bit number.

Thanks again for your work on this.

Steph

> Steph, Julian,
> The following is an attempt to determine the probability of a false
> positive, both with the TUF approach as defined in
> draft-ietf-tsvwg-tcp-ulp-frame-01.txt, and the semi draft that Julian
> proposed.
>




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