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

[kaname nishizuka <[e-mail]>]

Thank you for your comments,

> [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.
What you pointed out is reasonable enough, but our concern is that there 
are de-facto well-known port in 1024-32768 like 1433/tcp.
Especially in the static assignment, the subscriber who has a "dirty" 
range would be attacked more frequently than others.
We know that most of the NATs use the  entire port space from 
1024-65536, but we described it in the most safe side.
As you mentioned, the ratio of dynamic:static is the same.


> [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 agree with that. It's useful and it supports the logic.

Thanks,
kaname

(2013/04/03 7:03), Senthil Sivakumar (ssenthil) wrote:
> 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]
>


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