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

From: "Linjian Song" <[email-masked]>
Date: Fri, 3 Sep 2010 01:04:11 +0800

======= 2010-09-01 23:23:30 you wrote：=======

>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.
[linjian]:yes.In my opinion the problem here is just a tradeoff between efficience of address sharing and less logging.

to Tina: If a block of addresses is allocated per user. it will be embarrassing all the users are always online which is a trend in mobile internet. 
Each user may have only a few activities, Keep alive signaling for example, a block of address will be idle and wasted.
If the initial size of block is set relatively small, the help to reduce the NAT logging will be not obvious.   

Why not jump out the struggle in the tradeoff and try to change another angle. 

why not just analyze the full log offline and save the log you are intereted. There are three considerations:

1. Destination address. The sensitive service servers that need to traceback the source.

2. Destination port(the type of service). Web, Telnet, Email etc. Note that it is hard to identify P2P application by port now.

3. Type of packets. Is it really necessary to log the  signaling packets ? DNS query, TCP handshake and keepalive msg ? In addtion there are many pplications using the different ip+port in signaling and data transmission.such as FTP,SIP,IM app. In a simple test in my laptop shows that signaling packets consumes large part of port resource (roughly >50%)  I roughly identify the signaling packets by the duration of port useage and number of interactive packets. 

if we only save the log that really matters, the logging  problem may be eased.

Perhaps the idea is out of the scope of your solution. Expect more discussion on that issue.             

>
>On 9/1/10 3:28 AM, "Tina TSOU" <[email-masked]> wrote:
>
>> 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
>> http://tinatsou.weebly.com/index.html
>> 
>> ----- 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
>> 
>> 
>> 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.
>> 
>> 
>> On 9/1/10 12:35 AM, "Senthil Sivakumar (ssenthil)" <[email-masked]>
>> wrote:
>> 
>>> [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.
>> 
>> 
>> 
>
>_______________________________________________
>Behave mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/behave

= = = = = = = = = = = = = = = = = = = =

Best regards.   2010-09-02

********************************************************
*    Linjian Song ,Ph.D candidate                      *
*    Department of Computer Science & Technology       *
*    Tsinghua University, Beijing, P.R.China(100084)   *
*    Tel: (8610)-62795818-6864                         *
*    Email: [email-masked]                        *
********************************************************

---

From: Tina TSOU <[email-masked]>
Date: Fri, 03 Sep 2010 10:42:11 +0800

Hi Jin-Jian,
Thank you for your comments. As you said, some of what you discussed is out 
of scope. But it is also worthy to discuss in another thread.
It’s an approach of pertinence; it is specific for operators’ 
requirements. It is more applicable for broadband case.
If to do the analysis for application, it is not the business for operators. 
It’s not work for James Bond, not for operators.
However, it does not solve the NAT log issues, if the NAT deployment could 
be somehow simplified, since operators usually have some address storage, it 
is a good tradeoff.

B. R.
Tina
http://tinatsou.weebly.com

----- Original Message ----- 
From: "Linjian Song" <[email-masked]>
To: "Reinaldo Penno" <[email-masked]>; "behave" <[email-masked]>; 
"tena" <[email-masked]>
Sent: Friday, September 03, 2010 1:04 AM
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

> [linjian]:yes.In my opinion the problem here is just a tradeoff between 
> efficience of address sharing and less logging.
>
> to Tina: If a block of addresses is allocated per user. it will be 
> embarrassing all the users are always online which is a trend in mobile 
> internet.
> Each user may have only a few activities, Keep alive signaling for 
> example, a block of address will be idle and wasted.
> why not just analyze the full log offline and save the log you are 
> intereted. There are three considerations:
>
> 2. Destination port(the type of service). Web, Telnet, Email etc. Note 
> that it is hard to identify P2P application by port now.
>
> 3. Type of packets. Is it really necessary to log the  signaling packets ? 
> DNS query, TCP handshake and keepalive msg ? In addtion there are many 
> pplications using the different ip+port in signaling and data 
> transmission.such as FTP,SIP,IM app. In a simple test in my laptop shows 
> that signaling packets consumes large part of port resource (roughly >50%) 
> I roughly identify the signaling packets by the duration of port useage 
> and number of interactive packets.
>