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

"Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com> Wed, 03 April 2013 18:57 UTC

Return-Path: <ssenthil@cisco.com>
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 2711B21F8BF8 for <behave@ietfa.amsl.com>; Wed, 3 Apr 2013 11:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 rbnYsDFDl4fz for <behave@ietfa.amsl.com>; Wed, 3 Apr 2013 11:57:10 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5117021F8B6D for <behave@ietf.org>; Wed, 3 Apr 2013 11:57:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2946; q=dns/txt; s=iport; t=1365015430; x=1366225030; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=JN6jNTp9mXPNP7ZzF/N3GPGx83hYL0C/pQ2PQ1A+KqA=; b=eJvTHuyOqJCGxZmXNpOz2r+R3deOtP+8kZyuUuUL3UmUDMHHrj5l5RqN ZwLT/vHu7sMDhk4E971B1LucXcJz08EdejrB1jM2Ux1TMo+/gJjvPUhD7 +qnKT0NecAR4j5ys2f4zN79euIJcytAdrVI2R6qJO4RNtrZGzMz/CHmkU A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai0FABx7XFGtJV2b/2dsb2JhbABDgwc2wEiBDRZ0giEBBAEBAWcECRQBCCIZMgslAgQTCIgMDJ9DoQkEjW17OIJfYQOndoFVgTaBaz0
X-IronPort-AV: E=Sophos;i="4.87,402,1363132800"; d="scan'208";a="194769560"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 03 Apr 2013 18:57:06 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r33Iv6WX017733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <behave@ietf.org>; Wed, 3 Apr 2013 18:57:06 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.42]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 3 Apr 2013 13:57:06 -0500
From: "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
To: "behave@ietf.org" <behave@ietf.org>
Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt
Thread-Index: AQHOMJ0IkiEqeCVHx02R0YbUwz8tLA==
Date: Wed, 03 Apr 2013 18:57:05 +0000
Message-ID: <CB1B483277FEC94E9B58357040EE5D0232433A58@xmb-rcd-x15.cisco.com>
In-Reply-To: <515C35BD.7060503@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.117.198.132]
Content-Type: text/plain; charset="windows-1254"
Content-ID: <CA14221908069B4A8C9BACA9FD8B407E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 03 Apr 2013 18:57:11 -0000

On 4/3/13 9:59 AM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:

>Le 2013-04-03 15:19, Senthil Sivakumar (ssenthil) a écrit :
>>> My reaction was different. I was thinking "only 10:1, this is pretty
>>> good for static."
>>
>> Why so? With the same 15259 addresses that I have, I could add 10 times
>> more subscribers,
>> I can add up to 10Million subscribers as per this example, that is 10
>> times more
>> revenue. That was also the revenue lost, why is it good for business?
>
>You're assuming that the limiting factor is addresses. You're assuming
>that even with dynamic allocation, the ISP is going to "fill" all its
>available public space. That's not what the text says. All the text says
>is that dynamic allows ~10 times more users behind each address than
>static. Nowhere does it say that static isn't "good enough".

If it is not the address, what is the limiting factor? The reason ISP is
deploying CGN is the shortage of addresses and cant provide a single
address to each
of his subscribers. Maybe you meant to say the address is not the only
limiting factor.
I never said the text was saying static isnt good enough :-), I deduced
from the study that
the usage of ports is far more compellingly efficient with dynamic port
allocation and the cost
of logging infra can be justified.

Most of the studies in the past projected how bad the logging problem is
but didn’t have
any data on the other side of the equation on how inefficient the static
port allocation is.
I wouldn’t want this draft to say one is better than the other, but let
the operators choose, if 10:1
static to dynamic port allocation is justified for their deployment.

Senthil

>
>>>> 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
>>>
>>> The raw cost of storage is probably insignificant compared to those
>>> "other operating expenses"...
>>
>> Can you put a dollar value to the significant other operating expenses?
>> Does it offset the 10x revenue generated by doing dynamic
>> port allocation and logging ? I think the key would be what the business
>> proposition is at the end of the day.
>
>It would vary per organization. An organization that is already well
>equipped in logging infrastructure and procedures would have a much
>lower cost deploying additional logging for CGN. But an organization
>that doesn't have this infrastructure would quickly say "no way!" and
>would look hard for alternatives. But all this is over-generalization,
>of course.
>
>Simon
>_______________________________________________
>Behave mailing list
>Behave@ietf.org
>https://www.ietf.org/mailman/listinfo/behave