Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt

["Senthil Sivakumar (ssenthil)" <[e-mail]>]

Hi Kaname,
It is a pretty interesting study. I have a few comments on the sections on your IP address requirements calculations.In the dynamic assignment, the ports of pool address are allocated





"   # of pool address (P) = # of Subscriber (S) * a * N / (65536 - R)

   Here, (R) is reserved TCP/UDP port list referred in
   [I-D.donley-behave-deterministic-cgn<http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00#ref-I-D.donley-behave-deterministic-cgn>].  CGN should eliminate the
   wellknown ports (0-1023 for TCP and UDP) to avoid the bad
   interpretation from destination servers.  It is natural to translate
   source port of outgoing packet to ephemeral ports.  The ports after
   32768 is considered to be used without any problems because ephemeral
   ports are 32768-61000 for Linux and 49152-65535 in the IANA
   recommendations.  As the result, 3,051 pool addresses are sufficient
   for 1,000,000 subscribers.  The feasibility of configuration was
   confirmed in the verification."


[Senthil] Most of the NATs use the entire port space from 1024-65536, did you find differently?

If you had used the entire port space, you would only require 1526 addresses instead of 3051.

I think not using the 1024-32768 is not practical and inefficient.



   On the other hand, in static assignment, the ports are allocated a
   priori for every users.  The pool addresses and ports are reserved to
   every users, so most of them could be a dead stock because there are
   light users and heavy users in aspect of port consumption.  The max
   number of port consumption in all subscribers is the key value for
   static assignment.  The true peak number of the session by a heavy
   user could be over 10,000 sessions.  However it is assumed that such
   a severe consumption of ports to be an abuse, so the number of
   statically assigned port (M) is controllable parameter by each
   providers.  In the static assignment, the required number of the pool
   address is as follows:

   # of pool address (P) = # of Subscriber (S) * M / (65536 - R)

   Taking account into the investigation of number of sessions of
   applications, the desirable value of (M) is over 1,000.  As the
   result, no less than 30,517 pool addresses are needed for 1,000,000
   subscribers.  The compression ratio is one tenth of the case of
   dynamic assignment."


[Senthil] Going by the same standards of using the entire available port range, you should require 15259 addresses.
But the point is the cost of static allocation to dynamic allocation is 10:1, which is huge and given the fact there is only so little
address space that is available, it should be used efficiently. Just by looking at that calculation, it seems amply clear that dynamic is preferred over static,
as you have noted.
That leads us to the next topic on logging.



  " In addition, the indicator of the allocation and deallocation are
   needed because it assures that the identified subscriber certainly
   had been using the translated IP address and port.  Plus, including
   the index of the CGN host, the average size of NAT log is about 120
   byte in ASCII format.  Every active subscriber generate 400 sessions
   in average for a certain amount of time.  It is assumed that the
   event happens every 5 minute in the most severe condition.  The size
   of the log (L) for time frame (T) can be estimated as follows:

   The size of log (L) = # of Subscriber (S) * a * N * 120byte * 2 * (
   Time frame(T) / 5 min. )



   It should be noted that the log is generated at the timing of NAT
   table creation and freeing.  As the result, for 1,000,000 users, the
   size of log is piled up to 6.4 terabytes per day.  The verification
   result confirm the existing estimation referred in
   [I-D.donley-behave-deterministic-cgn<http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00#ref-I-D.donley-behave-deterministic-cgn>]."


[Senthil] I think it should be mentioned that with binary format for the above logging information, you need 26 bytes.

Transport Protocol -  1 byte

 Source IP address:port – 6 bytes
 Source IP address:port after translation – 6 bytes
 Timestamp – 8 bytes

 Add/Delete – 1 byte

 Subscriber ID/VRF ID – 4 bytes


I would help a lot to add the binary logging calculation in addition to the ascii format to help people choose the right method for them.

Going by the same formula you need 1.36 TB/day with binary logging. Assuming that the compression ratio is the same

For both ascii and binary data, you have 1/4-1/5th of advantage with binary logging.

You spread the cost of 1.36TB across a 1,000,000 subscribers assuming cost of 1TB is US$80,

we come to 0.00008 cents/subscriber/day or 0.024 cents/subscriber/month. Even with ASCII logging requirements this doesn’t sound like a mammoth cost.

Sure, there are other operating expenses involved but comparing that with the efficiency of a dynamic port allocation mechanism and requiring 10 times less

public addresses seems to be a compelling winning argument than changing every CGN implementation to save for logging costs.


Thanks

Senthil








From: kaname nishizuka <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 2, 2013 4:37 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Shin Miyakawa <[e-mail]<mailto:[e-mail]>>
Subject: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt


Dear all,

I'm kaname from NTT communications in Japan.
We are testing CGN under the support of Japanese Government.
Now, we've uploaded a new draft based on the result of our verification.
The useful information about the average consumption of the ports are available on the document.
Please look through it, and all kind of feedback are welcome.

By conducting realistic experiment, this draft is answering to "draft-ietf-behave-lsn-requirements-10" which will be the newest RFC very soon.

The document is *NOT* intended to be Standards Track. It's for Informational.
The wrong description is just mere mistake, so we'll soon correct it in the next revision.

The full report of our work will be available soon on the Web in English.
I'll also announce it when it's available to this mailing-list.

Best regards,

kaname





-------- Original Message --------
Subject:        New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt
Date:   Thu, 28 Mar 2013 07:12:25 -0700
From:   [e-mail]<mailto:[e-mail]>
To:     [e-mail]<mailto:[e-mail]>



A new version of I-D, draft-nishizuka-cgn-deployment-considerations-00.txt
has been successfully submitted by Kaname Nishizuka and posted to the
IETF repository.

Filename:        draft-nishizuka-cgn-deployment-considerations
Revision:        00
Title:           Carrier-Grade-NAT (CGN) Deployment Considerations.
Creation date:   2013-03-29
Group:           Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-nishizuka-cgn-deployment-considerations-00.txt
Status:          http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deployment-considerations
Htmlized:        http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00


Abstract:
   This document provides deployment considerations for Carrier-Grade-
   NAT (CGN) based on the verification result include the investigation
   of the number of sessions of applications.  The verification was
   conducted in StarBED which is one of the largest scale network
   experiment environment in Japan.  A million of subscribers was
   emulated and it revealed the realistic behavior of CGN.




The IETF Secretariat







--
----
Kaname Nishizuka
Innovative Architecture Center
NTT Communications Corporation
[phone]