Subject: Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifications and processor requirements at the agent

From: Randy Presuhn <[email-masked]>
Date: Tue, 28 Oct 2014 20:08:55 -0700 (GMT-07:00)

Hi -

>From: Simon Perreault <[email-masked]>
>Sent: Oct 27, 2014 6:35 AM
>To: Tom Taylor <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [OPSAWG] Major NAT MIB Issue: Notifications and processor requirements at the agent
...
>> draft-ietf-behave-nat-mib-11 triggers notifications based on the ratio of
>> active address and port mappings using a given pool to the total number of
>> address-port combinations made available by the pool, expressed as a
>> percentage. As David Harrington pointed out, this makes a lot of demands on
>> the agent processor. We have some alternatives:
...

I haven't seen David's original comment, but I don't see how
implementation to match the behaviour described here is
at all demanding computationally.

In a case like this, there are two pieces of information that
change infrequently: the threshold and the total number of
combinations made available by the pool; and one piece which
changes frequently: the number of active mappings using the pool.
A typical agent implementation strategy strategy for something like
this simply (re-)computes the *integer* threshold against which
the rapidly changing piece of information is to be compared.
All the "expensive" processing (typically just a couple of divisions
and multiplies) in terms of "ratios" only happens when processing
a *configuration* change. The frequent operation (threshold check)
is a simple integer compare in the same units as the variable of
interest.

Randy

---

From: Tom Taylor <[email-masked]>
Date: Wed, 29 Oct 2014 11:39:21 -0400

Good point, thanks.

Tom Taylor