Re: [Manet-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID

["Ian Chakeres" <[e-mail]>]

Clarifying comment.

On 5/2/07, Charles E. Perkins <[e-mail]> wrote:
>
> Hello Brian,
>
> I have some 'C' code that I have adapted
> from other sources, and if you like I can
> send it to you.  Of course you have to
> promise not to be too disappointed if you
> find bugs, and please send any improvements
> back to me so I can reincorporate it into
> the code I have.  It isn't very much, and
> at least half of it was grabbed from existing
> code on the net (including RFC 1321, which
> excuses me from any wrongdoing about the
> formatting and stylistic issues).
>
> Ian suggested that there was agreement
> that the hashing was effective, and asked
> whether the other features of the DPD
> header were sufficient to warrant its use
> (in favor of hashing).

My statement about hashing was that given different inputs to a
hashing algorithm, you get different outputs with high probability.

I am not convinced that hashing is the correct approach we should adopt for DPD.

> I do _not_ suggest that applications take
> any responsibility for generating unique
> hash codes.  To summarize, I prefer if we
> make hashing "good enough", and then use
> the DPD header for the rare cases where
> the hash function fails to distinguish different
> flooded packets.  Used in this way, the
> DPD header could be a lot simpler.
>
> Regards,
> Charlie P.
>
>
> ext Brian Adamson wrote:
> > Charlie, Teco
> >
> > Do either you have implementations of hash or packet lookup approaches
> > that we could try or incorporate into our "nrlsmf" implementation so
> > we can look at the performance/computation complexity/space trade-offs
> > more?
> >
> > I am concerned that complexity/space needed for these approaches may
> > be prohibitive for some applications (and I am curious about the
> > performance of the hash to not have false duplicates) compared to our
> > current approach.  But I am not opposed to allowing for both
> > approaches to be specified or options if appropriate.
> >
> > The other issue is that imposing a requirement on applications to
> > generate unique packet payloads (while probably generally good
> > practice) may be inappropriate for a network layer specification?
> >
> > Also, Teco had mentioned in an earlier email he was concerned that "a
> > bit table
> > with packets received with offsets to a sequence number base (as often
> > used
> > in IPsec replay detection code) is not usable" ... I am not sure if
> > that comment was limited to the fragmentation issue that was being
> > discussed or with regard to SMF DPD in general?  We have used this
> > sort of approach successfully with IPv4 and IPv6 in fairly extensive
> > laboratory and field tests for the past few years (although not with
> > any fragmentation).  However, it is not strictly a a packet bit mask,
> > a timer is used to detect/prune stale packet flows as well, and there
> > is a strategy involved to allow for the bitmask to provide a sort of
> > "sliding window"
> > _______________________________________________
> > Manet-dt mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/manet-dt
> >
>
>
>
> _______________________________________________
> Manet-dt mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/manet-dt
>


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