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

Olivier Vautrin <ovautrin@juniper.net> Sun, 05 September 2010 06:46 UTC

Return-Path: <ovautrin@juniper.net>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9303A63D3 for <behave@core3.amsl.com>; Sat, 4 Sep 2010 23:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Level:
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvPt8nxcQDxm for <behave@core3.amsl.com>; Sat, 4 Sep 2010 23:46:54 -0700 (PDT)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 9ECF03A659C for <behave@ietf.org>; Sat, 4 Sep 2010 23:46:48 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTIM88LUB6N/osts5RDQDPjfkwq5qsVP7@postini.com; Sat, 04 Sep 2010 23:47:24 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Sat, 4 Sep 2010 23:41:03 -0700
From: Olivier Vautrin <ovautrin@juniper.net>
To: "mohamed.boucadair@orange-ftgroup.com" <mohamed.boucadair@orange-ftgroup.com>, Lars Eggert <lars.eggert@nokia.com>
Date: Sat, 04 Sep 2010 23:41:01 -0700
Thread-Topic: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs
Thread-Index: ActLY4tyA5L9Ux7fST+ebAN8NFmuJAAACoJQAFfc3IA=
Message-ID: <84600D05C20FF943918238042D7670FD36D96A7BA1@EMBX01-HQ.jnpr.net>
References: <979A43C06A7B488B93D6FFBA8395A033@china.huawei.com> <9245BF3C-D02C-4C91-8690-C6261758701A@nokia.com> <17006_1283515801_4C80E599_17006_1679467_1_94C682931C08B048B7A8645303FDC9F31C501E6E33@PUEXCB1B.nanterre.francetelecom.fr> <55DD09BB-C144-4124-8080-332E8B4C0F7B@nokia.com> <26667_1283517256_4C80EB48_26667_79086_1_94C682931C08B048B7A8645303FDC9F31C501E6E60@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <26667_1283517256_4C80EB48_26667_79086_1_94C682931C08B048B7A8645303FDC9F31C501E6E60@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "behave@ietf.org" <behave@ietf.org>, Tina TSOU <tena@huawei.com>
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Sep 2010 06:46:58 -0000

Hello Med,

Does that mean you don't expect providers to Compress/Optimize the logs information sent per CGN device at all? 

In my understanding, this proposition will have an effect on the storage of log files only if the logs are kept *as is*. This is because the ports are randomly choosen in draft-tsou-behave-natx4-log-reduction-01, range are not created with contiguous ports so the amount of information sent by the CGN is not decreasing only the syslog message has changed.

Regards,
Olivier.

> > (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.