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

"Howard, Lee" <lee.howard@twcable.com> Wed, 03 April 2013 20:40 UTC

Return-Path: <lee.howard@twcable.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 9347B21F8E5C for <behave@ietfa.amsl.com>; Wed, 3 Apr 2013 13:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.963
X-Spam-Level:
X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1]
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 XEVfCIOTVX3A for <behave@ietfa.amsl.com>; Wed, 3 Apr 2013 13:40:12 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6654321F8E5A for <behave@ietf.org>; Wed, 3 Apr 2013 13:40:09 -0700 (PDT)
X-SENDER-IP: 10.136.163.14
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.87,403,1363147200"; d="scan'208";a="53028525"
Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 03 Apr 2013 16:39:41 -0400
Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 3 Apr 2013 16:40:05 -0400
From: "Howard, Lee" <lee.howard@twcable.com>
To: "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>, "behave@ietf.org" <behave@ietf.org>
Date: Wed, 03 Apr 2013 16:40:05 -0400
Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt
Thread-Index: Ac4wq2uqrjXCQTIUSeu2L+RgtNPEYA==
Message-ID: <CD820994.186B6%lee.howard@twcable.com>
In-Reply-To: <CB1B483277FEC94E9B58357040EE5D0232433A58@xmb-rcd-x15.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: text/plain; charset="windows-1254"
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 20:40:12 -0000

On 4/3/13 2:57 PM, "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
wrote:

>
>
>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".

I have not been following this thread closely, but it keeps popping up.
It doesn't say it's not good enough, but it spends two paragraphs
describing why it is inferior.
And says, "In the aspect of the efficiency, the dynamic assignment is
preferable
   than the static assignment.  However the size of the log is the main
   consideration."

I agree that there's an important consideration in whether more efficiency
is "compression ratio" is needed.  If static port allocation allows an ISP
to take the addresses they would normally consume in one month and make
them last for five years (60:1 compression), then just a month or a couple
of months' worth of addresses lasts through the transition.

By the way, improving your CGN does not increase revenue.

>
>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.

Maybe it should say, "IF the cost of logging can be justified."  Even 30%
of 6.2TB per day is a lot of data, and depending on your data retention
requirements, might require a significant system to retrieve records
efficiently.


>
>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.

It could be clearer in the draft.

Lee


>
>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
>
>_______________________________________________
>Behave mailing list
>Behave@ietf.org
>https://www.ietf.org/mailman/listinfo/behave


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.