Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

From: Tina TSOU <[email-masked]>
Date: Fri, 03 Sep 2010 18:15:54 +0800

B. R.
Tina
http://tinatsou.weebly.com

----- Original Message ----- 
From: "Lars Eggert" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 03, 2010 4:49 PM
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

Hi,

On 2010-8-28, at 12:18, Tina TSOU wrote:
> http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-01
> 
> It is a short, straight forward I-D. I would like to hear your opinion and more comments. What's the next step for it?

I'm struggling a bit to understand the motivation for this draft. In the introduction, it says:
[Tina: 
Hi Lars,
Thank you very much for your comments. BTW, I can never reply your email directly ‘cause it always asks getting the ID, since you encrypted your email.
I found I consolidate some thinking around reducing logging.
So I bring into play the Internet Spirit -- "sharing".
I think I talked NAT allocation policy and NAT log entries. I don’t have any other special motivation.
]

>   Some high performance NAT devices may need to create a large amount
>   of new sessions per second.  If logs are generated for each mapping
>   entry, the log traffic could reach tens of megabytes per second or
>   more, which would be a problem for log generation, transmission and
>   storage.

Let's run some numbers. How large is a log entry? Let's assume two IPv4 addresses plus two ports numbers, which is 12 bytes, plus a timestamp, which is maybe 4 bytes, plus some random bytes of stuff. Say, in total 32 bytes.

At a rate of     1,000 bindings/sec, that causes  32 KB/sec of log traffic.
At a rate of    10,000 bindings/sec, that causes 320 KB/sec of log traffic.
At a rate of   100,000 bindings/sec, that causes   3 MB/sec of log traffic.
At a rate of 1,000,000 bindings/sec, that causes  32 MB/sec of log traffic.

So we're really only going to his the "tens of megabytes per second" range for CGNs that see a million bindings per second. You'd need an awfully big box to handle this, and a significant amount of IPv4 space to number it.

As for storage, with a million bindings per second and 32 MB/sec of log traffic, you need about 2GB/min, i.e., 2.7 TB/day. And this is without compression - these logs should be highly compressable.

All in all, I'm not fully convinced we have a problem here. Or maybe I'm missing something?
[Tina: 
It takes storage resource, if the operator wants to pay it.
Even you take high compression, you need to do de-compression, and the search is not so easy.

Furthermore, you said that 
“At a rate of 1M bindings/sec, you need about 2GB/min, i.e., 2.7 TB/day without compression. Since it is high compression, so there is no problem“.

In the IPv6 evolution, if we adtopt DS-Lite or NAT64, the entry of log would be longer, 44 bytes or even longer. If the number of the users which CGN supports is few, there will be many CGNs in a network. If the CGN is in a higher position in the network, and consider many enough intercurrent sessions (e.g. Google MAP sometimes needs more than 300 connections). The performance of 1,000,000 bindings/sec is not enough. The entire device needs to support more. Let’s have the example of 10,000,000 bindings/sec, 44 Bytes entry.

At a rate of 10,000,000 bindings/sec, that causes 440 MB/sec of log traffic. We need about 26.4GB/min, which is 10 times of the example you gave.
]

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Sep 2010 13:43:20 +0300

Hi,

> Thank you very much for your comments. BTW, I can never reply your email directly ‘cause it always asks getting the ID, since you encrypted your email.

it's not encrypted - it's cleartext with an S/MIME signature attached.

> Even you take high compression, you need to do de-compression, and the search is not so easy.

You don't need to decompress to search. And even if you did, you wouldn't need to decompress one entire huge file.

> At a rate of 10,000,000 bindings/sec, that causes 440 MB/sec of log traffic. We need about 26.4GB/min, which is 10 times of the example you gave.

It's ten times the rate I gave because you went from one million bindings per second to ten million bindings per second :-)

But OK, let's run with the 10 million bindings per second number. Let's assume they're all for TCP connections, and let's assume each connection is really short, such that it only sends ten packets during one second and then stops.

That means that box is going to need to handle 100 million TCP segments per second. Assuming the usual 1500 byte segment size, that hypothetical CGN box would need to support a bandwidth of 1200 Tb/sec. That's clearly infeasible. (And if you assume that connections last longer or send at higher rates, that bandwidth requirement is going *up*, if the binding rate stays at 10 million per second.)

So I remain unconvinced that these binding rates are realistic. If anyone has access to a core router, can you get us some NetFlow numbers on how many SYNs you see per second? That should be the same ballpark.

Lars