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

["Douglas Otis" <[e-mail]>]

Steph,

Schemes exclusively supporting layers prior to TCP, used in conjunction with
application designators for placement, are advocating a TCP/application
transport amalgam depreciating the TCP interface paradigms.  There is an
effort at adding a shim to SCTP as a generalization of placement
capabilities.  This TCP amalgam concept introduces a new transport and
interface that should attempt application consolidation if such changes are
allowed.  Would you see a benefit in combining generalized structures found
within the SCTP shim within these various introductions of a new layer for
framing and "out of sequence" synchronization for direct placement within
TCP?

Doug

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


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