Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports?

ivan c <ivan@cacaoweb.org> Sun, 16 June 2013 22:24 UTC

Return-Path: <ivan@cacaoweb.org>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4007A21F9D3A for <behave@ietfa.amsl.com>; Sun, 16 Jun 2013 15:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3FlSOqbTTlM for <behave@ietfa.amsl.com>; Sun, 16 Jun 2013 15:24:22 -0700 (PDT)
Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id BBAB121F9D27 for <behave@ietf.org>; Sun, 16 Jun 2013 15:24:22 -0700 (PDT)
Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from <ivan@cacaoweb.org>) id 1UoLNi-0001Ll-UH; Mon, 17 Jun 2013 00:25:06 +0200
To: <behave@ietf.org>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_d9393dc2356d000a176ce6bac8d0b70b"
Date: Mon, 17 Jun 2013 00:25:06 +0200
From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
Message-ID: <6d6816c3367bc3c3bcf3795fbc850701@cacaoweb.org>
X-Sender: ivan@cacaoweb.org
User-Agent: RoundCube Webmail/0.3.1
Cc: rajiva@cisco.com
Subject: Re: [BEHAVE] =?utf-8?q?=5Bv6ops=5D_Home_NAPT44_-_How_many_ports=3F?=
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ivan@cacaoweb.org
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2013 22:24:27 -0000

On Jun 6, 2013, at 5:41 PM, "Rajiv Asati (rajiva)"  wrote:

> Hi Dan,
>

>> and so on. I am surprised you conclude that "500 seems ok" when such
a
>> limit would interfere with your network use on those days.
> 
> I
based that statement ("...seems ok,") on the very fact that the number of
times the NAT utilization exceeded 500 mappings (equating to 500 ports, in
my setup) in the sample period (~2 months) was relatively quite low. So, if
the NAT device was limited to only 500 mappings, then the experience would
have been ok for 99% of the time and degraded 1% of the time. This is an
important consideration, IMO.
> 
> For ex, in the last 2 weeks, the number
of times NAT mappings exceeded 500 were:
> 
> June 3 - 1 time
> May 29 - 1
time
> May 28 - 3 times
> May 26 - 1 time
> May 23 - 1 time
> May 22 - 2
times
> May 21 - 3 times
> 
> Of course, 1000 ports (resulting in 1000+
mappings) would have been more than enough to accommodate the times when
the mappings exceeded 500, but stayed within 1000 (except once).
> 
> 
>>
What is the maximum number of mappings supported by your NAPT device?
>>
Some residential-class NATs have a limit of 1024 mappings.
> 
> My NAPT
device seemingly can use upto 64K ports. :)
> 
> Cheers,
> Rajiv

I'm not
sure whether observing traffic on your local personal internet correction
and then extrapolating this behavior for the worldwide internet as a whole
is a very scientific method, especially when the purpose is the redaction
of normalization and interoperability documents. But it's surely an
interesting exercise. I noticed that in your experiment you leave out
popular protocols like bittorrent, which makes up most of the internet
world traffic and would surely gain to be integrated in such data series.


On the other hand, some people on this mailing list (who work at large
ISPs, or core network routers manufacturers) have access to would look more
like real-world statistical data and we should probably turn to them to get
proper information about what is currently happening on the inter networks.


-- 
_Ivan C._