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

From: Tina TSOU <[email-masked]>
Date: Wed, 01 Sep 2010 15:05:25 +0800

B. R.
Tina
http://tinatsou.weebly.com/index.html
----- Original Message ----- 
From: "Reinaldo Penno" <[email-masked]>
To: "Tina TSOU" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 31, 2010 11:49 PM
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

> Hello Tina,
>
> We have experience with this method and would like to suggest the 
> following
> be explained in the draft.
[Tina:] Reinaldo, thank you for your kind sharing and suggestion. Will 
explain them in -02 version.

>
> 1 - What is a user? A private source IP address?

[Tina] It depends, it could be a private source IP address, or tunnel ID, 
etc.

If the users could be distinguished by private source IP address, I could 
say a private source IP address stands for a user.

But in some case, i.e. DS-Lite, all the users may have a same private IP 
address, and then users should be distinguished by tunnel ID.

>
> 2 - Sessions that use the ports within a block will end at different 
> times.
> Do you return the ports to the main port pool?
>
> 2.1  - If you return the ports individually to the pool you will not have
> contiguous ports after some time (even if you want to). If you do not not,
> your basically statically carving out resources and making poor use of the
> port space.

[Tina] Conceptually there is a port pool for each user, and there are port 
blocks in the pool.
If no ports in a block is in user for a period of time, e.g. 5minutes (TBD), 
this port block should be released and could be assigned to another user.
There should be no "not-continuous" problem.

>
> 3 - If you log the deallocation for every port how much are you actually
> saving? If you wait for all ports to be freed to send a single log, it 
> might
> take a long time and you are back to statically carving out resources.
[Tina] just one log would be generated for a port block, not for each port.

>
> 4 - If the port are not contiguous you save the source IP and Dest IP but
> still need to list every port. The main effect of not having contiguous 
> port
> is that the allocation of ports takes much longer whenever a 'user' is 
> seen.
[Tina] see above.

>
> 4.1 - When will you 'forget' about a user? If you forget about it when all
> his/her sessions are are gone, you will be trying to allocate blocks of
> ports often.

[Tina] When all a user's secessions are gone for a period of time (TBD), I 
may say this user gets offline, and this entire user's resource could be 
de-allocated.
>
> Thanks,
>
> Reinaldo
>
>
> On 8/28/10 2:18 AM, "Tina TSOU" <[email-masked]> wrote:
>
>> Hi Behaver,
>> Here is an updated version, thanks to the wonderful review from Med.
>> 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?
>>
>>
>> B. R.
>> Tina
>> http://tinatsou.weebly.com/index.html
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 1 Sep 2010 03:12:40 -0400

Hummm....let me put another way.

Subscriber A is allocated ports 1000-1200. After 5 minutes ports 1050, 1051,
1060, 1070, 1077 have not been used and therefore you return them to the
pool. 

Another subscriber comes in and is allocated ports 1201-1398, 1060 and 1070.

Now multiply this by million users. The port range gets fragmented.

Therefore after a short period all allocation of ports will be non
continuous.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 1 Sep 2010 00:35:16 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Reinaldo Penno
Sent: Wednesday, September 01, 2010 3:13 AM
To: Tina TSOU; [email-masked]
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale
NATs

Subscriber A is allocated ports 1000-1200. After 5 minutes ports 1050,
1051, 1060, 1070, 1077 have not been used and therefore you return them
to the pool. 

[Senthil] I would think the port ranges are allocated/deallocated in
blocks to avoid fragmentation. Otherwise, 
it would prove difficult to manage the ports within a short span of
time. The question now may be how is oversubscription handled. For
instance, subscriber A is idle and not using his ports for the past n
minutes and subscriber Z wants more ports because he is actively
opening/closing connections but doesn't have any ports, what do we do. I
guess that is a network administration issue to solve. 

Another subscriber comes in and is allocated ports 1201-1398, 1060 and
1070.

On 9/1/10 12:05 AM, "Tina TSOU" <[email-masked]> wrote:

>> 2.1  - If you return the ports individually to the pool you will not 
>> have contiguous ports after some time (even if you want to). If you 
>> do not not, your basically statically carving out resources and 
>> making poor use of the port space.
> 
> [Tina] Conceptually there is a port pool for each user, and there are 
> port blocks in the pool.
> If no ports in a block is in user for a period of time, e.g. 5minutes 
> (TBD), this port block should be released and could be assigned to
another user.

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 1 Sep 2010 03:40:54 -0400

Agreed. I mentioned on the first email that there are basically two choices:

* Individual port release which in the long run leads to fragmentation but
better resource use.

* Or allocating/releasing in blocks of well-known size which in a sense is
almost a static division given a number N of subscribers.

---

From: Tina TSOU <[email-masked]>
Date: Wed, 01 Sep 2010 18:28:45 +0800

Big pool and small pool are containing relationship. Release the port first 
to the small pool. After finishing releasing all the ports in the small 
pool, release the port to the big port. Here we go, there is no 
fragmentation.

B. R.
Tina

----- Original Message ----- 
From: "Reinaldo Penno" <[email-masked]>
To: "Senthil Sivakumar (ssenthil)" <[email-masked]>; "Tina TSOU" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, September 01, 2010 3:40 PM
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 1 Sep 2010 11:23:30 -0400

Sure, but then your port available space is divided by the size of your
small pool and it will impact how many subscribers you can handle.

---

From: Tina TSOU <[email-masked]>
Date: Thu, 02 Sep 2010 17:14:52 +0800

Based on the Stat. result (e.g. average TCP connections when visits 
Internet), one can identify how to settle port range. In addition,

(1)     The operator deploys NAT device, he needs to consider utmost 
situation: all users are in the high intercurrent connection case; actually, 
this case rarely happens. So the port resource is sufficient, even he 
allocates by blocks. If there is high intercurrent situation, as long as the 
port size is appropriate, there will not be any port resource insufficiency.

(2)     Merits: Many Internet visits are multiple TCP connection 
intercurrent, e.g. Google map. If the port range mechanism is adopted, it 
can reduce the burden of searching idle ports resource in this case, and 
fasten the intercurrent NAT table building up speed.

B. R.
Tina
----- Original Message ----- 
From: "Reinaldo Penno" <[email-masked]>
To: "Tina TSOU" <[email-masked]>; <[email-masked]>; "Senthil Sivakumar 
(ssenthil)" <[email-masked]>
Sent: Wednesday, September 01, 2010 11:23 PM
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs