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

From: Brian Adamson <[email-masked]>
Date: Wed, 2 May 2007 12:37:43 -0400

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"

At 8:58:02 AM -0700 4/27/07, Charles E. Perkins wrote:

>Hello Teco,
>
>>ext Teco Boot wrote:
>>If memory is really cheap and memory lookups can be performed faster than
>>hash calculations, the DPD code could use packet header lookup instead of
>>hash lookup. Functionality is the same.
>Check.
>>Both mechanisms rely on unique
>>packet headers (say 1st 64 bytes or defined fields).
>The defined fields could include some amount of payload.
>>
>>That is what should be
>>specified in the standard. Which method is used for verifying duplicates is
>>an implementation issue.
>I think for IPv6 has also to specify which hash function
>to use.  For IPv4 I am hoping we do not need a hash function or any 
>DPD header.
>Regards,
>Charlie P.

-- 
Brian
__________________________________
Brian Adamson
<mailto:[email-masked]>

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 May 2007 11:09:36 -0700

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

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

---

From: Brian Adamson <[email-masked]>
Date: Wed, 2 May 2007 16:44:04 -0400

Charlie,

Whatever 'C' code you have we might be able to work with in some way. 
Better yet if you had a full-up forwarding engine we could use ... 
But we can do a little work here and I'm not afraid of bugs (I do a 
nice job of cultivating my own herd of those), etc.  I just would 
like to compare the space/complexity needed with each approach.

Wr2 to a simpler SMF DPD option, it's hard to do much simpler for 
IPv6 because of the multiple of 8 octets sizing that IPv6 option 
headers require ... yes, _some_ savings might be garnered under 
certain conditions when other options were also present, but the 
current SMF DPD options adds the minimum possible to an IPv6 its the 
only option added.

At 11:09 AM -0700 5/2/07, Charles E. Perkins wrote:
>>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 
>>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"

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 May 2007 14:02:47 -0700

Hello Brian,

The option could be simpler, because its only purpose would
be to distinguish different flooded packets.  Since any node
adding this option would use the same hash to find if there
had been a collision recently, there would be no need for the
Tagger ID.  I reckon that the data field for the option might
only have to be one byte, but of course there is all the glue.

Regards,
Charlie P.

ext Brian Adamson wrote:
> Wr2 to a simpler SMF DPD option, it's hard to do much simpler for IPv6 
> because of the multiple of 8 octets sizing that IPv6 option headers 
> require ... yes, _some_ savings might be garnered under certain 
> conditions when other options were also present, but the current SMF 
> DPD options adds the minimum possible to an IPv6 its the only option 
> added.

---

From: Brian Adamson <[email-masked]>
Date: Wed, 2 May 2007 17:08:40 -0400

That was my point.  The "glue" to get an IPv6 option header added 
makes the difference of whether the SMF DPD option data field is one 
byte or three bytes (the suggested format that supports the TaggerId 
concept) almost inconsequential since in many cases this will likely 
be the only option added ... But all the trade-offs need to go into 
the decision bucket.

At 2:02 PM -0700 5/2/07, Charles E. Perkins wrote:
>>current SMF DPD options adds the minimum possible to an IPv6 its 
>>the only option added.

---

From: "Ian Chakeres" <[email-masked]>
Date: Thu, 3 May 2007 13:39:43 +0530

Clarifying comment.

> header were sufficient to warrant its use

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.