Subject: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage

From: Tom Taylor <[email-masked]>
Date: Fri, 20 Sep 2013 16:24:10 -0400

What is the intended relationship between these two counters. More 
specifically, is natPoolRangeAllocatedPorts incremented once per 
port-protocol combination allocated, or once when any protocol is 
allocated a given a port value, and not again for the same port value 
until it is subsequently freed?

As I mentioned in an earlier private E-mail, I'd like to see 
natPoolUsage calculated based on the second alternative, but I'd be 
happy to see natPoolRangeAllocatedPorts incremented once per 
port-protocol combination. That would give the operator a fuller picture 
of address pool activity.

Tom Taylor

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 20 Sep 2013 20:35:08 +0000

>until it is subsequently freed?

If you have 10 addresses in the pool, each address has 10k ports allocated
(TCP or UDP),
natPoolRangeAllocatedPorts counter will say 100k ports allocated.

poolUsage is a percentage value. Not sure I remember why we decided to
have two values..

Thanks
Senthil

---

From: Dave Thaler <[email-masked]>
Date: Fri, 20 Sep 2013 22:03:58 +0000

In MIB design one usual rule of thumb is you shouldn't have an object if its
value can be trivially computed by the client from the values of other objects.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Senthil Sivakumar (ssenthil)
> Sent: Friday, September 20, 2013 1:35 PM
> To: Tom Taylor; 'Simon Perreault'
> Cc: [email-masked]
> Subject: Re: [BEHAVE] NAT MIB: Relationship between
> natPoolRangeAllocatedPorts and natPoolUsage
> 
> 
> 
> (TCP or UDP), natPoolRangeAllocatedPorts counter will say 100k ports
> allocated.
> 
> >port-protocol combination. That would give the operator a fuller
> >picture of address pool activity.
> >
> >Tom Taylor
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Tom Taylor <[email-masked]>
Date: Fri, 20 Sep 2013 21:45:15 -0400

> If you have 10 addresses in the pool, each address has 10k ports allocated

[PTT] or both??

> poolUsage is a percentage value. Not sure I remember why we decided to

poolUsage is over the whole pool. natPoolRangeAllocatedPorts is for a 
sub-range of addresses within the pool. The percentage is useful for 
thresholding, I suppose.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 23 Sep 2013 11:31:45 +0200

Le 2013-09-21 03:45, Tom Taylor a écrit :
> sub-range of addresses within the pool.

Precisely.

I'm not sure that natPoolUsage can be "easily" computed from individual
natPoolRangeAllocatedPorts because there may be a lot of ranges, and
walking them all could quickly become impractical.

Simon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Sep 2013 11:54:59 +0200

> walking them all could quickly become impractical.

A slightly different question: How fast do these numbers change? Is
reporting a snaphost really useful here?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 23 Sep 2013 12:01:39 +0200

> reporting a snaphost really useful here?

On a big NAT with large pools, I would expect the numbers to oscillate
with a 24-hour period. When graphed, they would look similar to total
bandwidth graphs. I think both objects can be very useful and are
definitely needed.

(An aside: on a busy node, byte counters change *very* often. The point
of providing a snapshot is to make graphs and such. The exact value at a
precise moment is not what's interesting. It's the trend.)

Simon

---

From: Andrew Donati <[email-masked]>
Date: Mon, 23 Sep 2013 23:13:03 -0400

Some operators have alluded to using performance history tables.

-Andy 

> On Sep 23, 2013, at 6:01 AM, Simon Perreault <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Sep 2013 06:44:25 +0200

> precise moment is not what's interesting. It's the trend.)

Simon,

byte counters are just that - counters. You can poll them at whatever
granularity you want (within bounds). Such counters integrate how much
data has passed over time - you do not 'miss' any bytes.  What we have
here seems very different. If the pool usage fluctuates heavily over
short time scales (which I naively assume to be the case), then what
is the right granularity to read these objects? The objects do not
integrate and accumulate history since they report only a current
snapshot. It would perhaps make more sense to have counters instead of
snapshot values, e.g. the number of allocations and deallocations that
have been done so that I do not have to poll at a very high rate to
obtain a reasonably accurate idea of the situation.

/js

---

From: Dave Thaler <[email-masked]>
Date: Tue, 24 Sep 2013 05:05:38 +0000

> Behalf Of Juergen Schoenwaelder
> Sent: Monday, September 23, 2013 9:44 PM
> To: Simon Perreault
> Cc: [email-masked]; Tom Taylor
> > (An aside: on a busy node, byte counters change *very* often. The
> > point of providing a snapshot is to make graphs and such. The exact
> > value at a precise moment is not what's interesting. It's the trend.)
> 
> Simon,
> 
> data has passed over time - you do not 'miss' any bytes.  What we have here
> seems very different. If the pool usage fluctuates heavily over short time
> scales (which I naively assume to be the case), then what is the right
> granularity to read these objects? The objects do not integrate and
> accumulate history since they report only a current snapshot. It would
> perhaps make more sense to have counters instead of snapshot values, e.g.
> the number of allocations and deallocations that have been done so that I do
> not have to poll at a very high rate to obtain a reasonably accurate idea of the
> situation.

+1

=Dave

---

From: Simon Perreault <[email-masked]>
Date: Tue, 24 Sep 2013 10:48:43 +0200

> obtain a reasonably accurate idea of the situation.

Understood! Thanks for this very good suggestion!

We already have number of allocations/deallocations for the mappings
themselves, we can just do the equivalent for pools and get rid of the
usage percentage.

Simon

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 24 Sep 2013 07:51:25 -0400

+1

David Harrington
[email-masked]
+1-603-828-1401

> Behalf Of Dave Thaler
> Sent: Tuesday, September 24, 2013 1:06 AM
> To: Juergen Schoenwaelder; Simon Perreault
> here
> > the number of allocations and deallocations that have been done so that
I
> do
> > not have to poll at a very high rate to obtain a reasonably accurate
idea of
> the