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

Randy Presuhn <randy_presuhn@mindspring.com> Wed, 29 October 2014 03:09 UTC

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=K6w5Lollo21LK1kAt+UsTYB8AQi5md07z79VMAWA3jYy1GrlRRjwGXLdSqK52InM; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Message-ID: <28462556.1414552135464.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
Date: Tue, 28 Oct 2014 20:08:55 -0700
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: Simon Perreault <sperreault@jive.com>, Tom Taylor <tom.taylor.stds@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/behave/MCsyAyENIsGXyE3e1EiQrRAfHGU
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifications and processor requirements at the agent
Precedence: list
Reply-To: Randy Presuhn <randy_presuhn@mindspring.com>

Hi -

>From: Simon Perreault <sperreault@jive.com>
>Sent: Oct 27, 2014 6:35 AM
>To: Tom Taylor <tom.taylor.stds@gmail.com>
>Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "behave@ietf.org" <behave@ietf.org>
>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

[BEHAVE] Major NAT MIB Issue: Notifications and p… Tom Taylor
Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifi… Simon Perreault
[BEHAVE] Out of port errors, resource errors in N… Tom Taylor
Re: [BEHAVE] Out of port errors, resource errors … Simon Perreault
Re: [BEHAVE] Out of port errors, resource errors … JF Tremblay
Re: [BEHAVE] [OPSAWG] Out of port errors, resourc… Tom Taylor
Re: [BEHAVE] [OPSAWG] Out of port errors, resourc… JF Tremblay
Re: [BEHAVE] [OPSAWG] Out of port errors, resourc… Tom Taylor
Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifi… Randy Presuhn
Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifi… Tom Taylor