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

[Tom Taylor <[e-mail]>]

Good point, thanks.

Tom Taylor

On 28/10/2014 11:08 PM, Randy Presuhn wrote:
> Hi -
>
>> From: Simon Perreault <[e-mail]>
>> Sent: Oct 27, 2014 6:35 AM
>> To: Tom Taylor <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
>> 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
>