Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Lars Eggert [mailto:lars.eggert@nokia.com] 
Envoyé : vendredi 3 septembre 2010 14:28
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Tina TSOU; behave@ietf.org
Objet : Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

Hi,

On 2010-9-3, at 15:09, mohamed.boucadair@orange-ftgroup.com wrote:
> (1) The performance of the device are not impacted due to the writing operation (of each individual binding). For some implementations, we have seen a severe degradation when the device (in our case, it is a CGN DS-Lite) must log each individual entry. Note that, we have seen some implementations which loss packets when the port range bindings are not yet in place. But, I guess this is implementation-specific. 

right, I wouldn't diagnose a fundamental issue with the technology based on one implementation that has issues.

> (2) The amount of new sessions to be handled per second are drastically enhanced when a port range scheme is used instead of individual port assignment.

You still need to install or at least update a binding for each connection, in order to keep track of which external ports in the range are in use or available, and keep track of which internal port maps to which external port.

Med: Yes, but you don't need to log it and this why the performance are enhanced.

> (3) As an aside effect, when port ranges are used the size of the log file is optimised (FWIW, see http://tools.ietf.org/html/draft-boucadair-port-range-02#section-15.2 for a simplified exercise). Of course this optimisation depends on length of the port range.

I understand that ranges shorten the log file. The point I was trying to make is that even on very large CGNs (large enough so that they'd need an insane amount of bandwidth to forward all the traffic they're seeing), the log sizes are not unmanageable. Sure, they can always be reduced, but that's an optional optimization.

Med: When the factor is 1000, then optimisation can not be seen as a luxe.

Lars

> (4) The drawback of assigning port ranges in the CGN is that the destination address is not kept by the device. This may not be convenient in early stages of deployment of shared IP mechanisms in SPs domains. Indeed: 
> 
> (a) If a high address sharing ratio (e.g., 1:1000) is used, to avoid revealing the identity of all subscribers sharing the same address to answer to an abuse complaint by the authorities, we may rely on the destination address as an indicator to identify a/the concerned customer. In the meantime, we need to encourage servers to log the source port number in addition to the destination IP address. 
> (b) If a small address sharing ratio (e.g., 1:5) is used, storing the destination address in the CGN may not be useful. 
> 
> 
> Cheers,
> Med 
> 
> -----Message d'origine-----
> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Lars Eggert
> Envoyé : vendredi 3 septembre 2010 10:49
> À : Tina TSOU
> Cc : behave@ietf.org
> Objet : 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:
> 
>>  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?
> 
> Lars
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees. 
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. 
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
> 


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************