Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 17 May 2013 05:42:40 +0000

> Distributed solution: Take IP traffic directly from access router to the
>Internet.

Counter argument.

It implies, LI, Charging, DPI Šetc on each of the distributed nodes.
Implies more "CAPEX and OPEX" ?

I'm not against distributed models and 6909 is the proof point. But, IMO,
it will hard to draw relation to cost models, based on traffic exit
points. You may need mobility hierarchy in the network for "n" number of
reasons and a centralized models for "m" number of reasons. It more about
deployment choice, dependent on many parameters.

Sri

On 4/29/13 5:29 AM, "Alper Yegin" <[email-masked]> wrote:

>Hi Charlie,
>
>No, it should be less.
>
>Distributed solution: Take IP traffic directly from access router to the
>Internet.
>Centralized solution: Take IP traffic from access router to a core router
>to the Internet.
>
>The latter suggests more CAPEX and OPEX.
>
>Alper
>
>
>
>On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:
>
>> 
>> Hello Alper,
>> 
>> I agree with your point, but it means that the total cost of
>> the distributed solution is even more expensive.... right?
>> 
>> Regards,
>> Charlie P.
>> 
>> On 4/26/2013 12:56 AM, Alper Yegin wrote:
>>> Hi Charlie,
>>> 
>>>> - It is claimed that a centralized architecture requires more
>>>>resources
>>>>  than a distributed architecture.  This is usually false.  For
>>>>instance,
>>>>  if a centralized node requires 100 units, and 100 distributed nodes
>>>>each
>>>>  require 1.03 units, the distributed architecture requires 3 more
>>>>units
>>>>  overall.
>>> This would be true for tasks that can be performed either on the
>>>distributed node or on the central node.
>>> But the essential task for DMM systems, IP forwarding, is not of that
>>>nature.
>>> In centralized architecture, that task needs to be performed *both* at
>>>the edge node and also at the central node (and in fact even in
>>>between) before the packets hit the Internet/mobile device.
>>> 
>>> 
>>>> Even so, the additional expense of the distributed architecture
>>>>  would often be a bargain for reasons of redundancy, resiliency, etc.
>>> 
>>> Alper
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> dmm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dmm
>>> 
>> 
>> 
>> -- 
>> Regards,
>> Charlie P.
>> 
>
>_______________________________________________
>dmm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmm

---

From: Peter McCann <[email-masked]>
Date: Fri, 17 May 2013 13:04:46 +0000

We shouldn't require all the traffic to pay the price of centralization
just because some small subset of the flow need it.  LI should be a very
small proportion of the traffic, and those flows can be directed to a
collection point as needed.  If you really need per-flow, per-application
charging, you can send meta-information about the flows to a charging
collection box.  No need to send the flows themselves.

-Pete

Sri Gundavelli (sgundave) wrote:
> 
>> Distributed solution: Take IP traffic directly from access router to
>> the Internet.
> 
> 
> 
> 
> Counter argument.
> 
> 
> I'm not against distributed models and 6909 is the proof point. But,
> IMO, it will hard to draw relation to cost models, based on traffic
> exit points. You may need mobility hierarchy in the network for "n"
> number of reasons and a centralized models for "m" number of reasons.
> It more about deployment choice, dependent on many parameters.
> 
> 
> 
> 
> Sri
> 
> 
> 
> 
> 
> 
>> Distributed solution: Take IP traffic directly from access router to
>> the Internet.
>> Centralized solution: Take IP traffic from access router to a core
>> router to the Internet.
>> 
>>> I agree with your point, but it means that the total cost of the
>>> distributed solution is even more expensive.... right?
>>> 
>>> Regards,
>>> Charlie P.
>>> 
>>>>>  instance, if a centralized node requires 100 units, and 100
>>>>>  distributed nodes each require 1.03 units, the distributed
>>>>>  architecture requires 3 more units overall.
>>>> But the essential task for DMM systems, IP forwarding, is not of
>>>> that nature.
>>>> In centralized architecture, that task needs to be performed
>>>> *both* at the edge node and also at the central node (and in fact
>>>> even in

---

From: "KIM, BYOUNG-JO J (BYOUNG-JO)" <[email-masked]>
Date: Fri, 17 May 2013 10:23:42 -0400

Very much agreed.

Also, distributed solutions can be concentrated as deployment needs dictate using layer 2 means, as is done often in many present networks.

can't do the opposite with centralized solutions without a whole lot of acrobatics.

"J" Kim
AT&T Labs - Research
http://sites.google.com/site/macsbug/

---

From: h chan <[email-masked]>
Date: Fri, 17 May 2013 21:07:12 +0000

The original comment was on "resources" in the following problem statement:

   PS3:  Low scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN therein requires more resources in
         a centralized design, thus reducing scalability.  Distributing
         the tunnel maintenance function and the mobility context
         maintenance function among different network entities can
         increase scalability.

How about revising PS3 to the following and comparing resources:

   PS3:  Low scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN in a centralized design increase
         the processing at the anchor as the number of MNs increases.
         Distributing the tunnel maintenance function and the mobility
         context maintenance function among different network entities
         with proper signaling protocol design can increase scalability.

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of KIM, BYOUNG-JO J (BYOUNG-JO)
Sent: Friday, May 17, 2013 9:24 AM
To: Peter McCann
Cc: [email-masked]
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Very much agreed.

"J" Kim
AT&T Labs - Research

On May 17, 2013, at 9:04 AM, Peter McCann wrote:

> We shouldn't require all the traffic to pay the price of 
> centralization just because some small subset of the flow need it.  LI 
> should be a very small proportion of the traffic, and those flows can 
> be directed to a collection point as needed.  If you really need 
> per-flow, per-application charging, you can send meta-information 
> about the flows to a charging collection box.  No need to send the flows themselves.
> 
> -Pete
> 
> 
>>>>>> resources than a distributed architecture.  This is usually 
>>>>>> false.  For instance, if a centralized node requires 100 units, 
>>>>>> and 100 distributed nodes each require 1.03 units, the 
>>>>>> distributed architecture requires 3 more units overall.

---

From: h chan <[email-masked]>
Date: Sat, 18 May 2013 04:47:28 +0000

The original comment was on "resources" in the problem statement PS3:

How about revising PS3 to the following without comparing resources:

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of KIM, BYOUNG-JO J (BYOUNG-JO)
Sent: Friday, May 17, 2013 9:24 AM
To: Peter McCann
Cc: [email-masked]
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Very much agreed.

"J" Kim
AT&T Labs - Research

---

From: Alper Yegin <[email-masked]>
Date: Mon, 20 May 2013 10:24:41 +0300

> Implies more "CAPEX and OPEX" ?

If that were the case, then the operators wouldn't be offloading the subscriber IP traffic from WiFi to Internet. 

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 20 May 2013 17:27:26 +0000

Pete,

> We shouldn't require all the traffic to pay the price of centralization

I'm not suggesting that. Split model, with partial subset of the flows
going through a central anchor and part of the other traffic breaking out
locally is fine. My comment is not tie "cost" as the only argument for
enabling LBO models. Its a deployment consideration that drives that
decision. It may be about the availability of internet peering points, or
many other considerations.

> LI should be a very small proportion of the traffic, and those flows can
>be directed to a collection point as needed.

You mean small set of subscribers, or small portion of a subscriber
traffic. ? 
If its later, I assumed the Communication Content (CC) for intercept (in
general) is HTTP+SMTP traffic which in most cases maps to 100% of the
subscriber traffic.

Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 20 May 2013 17:29:53 +0000

> If that were the case, then the operators wouldn't be offloading the
>subscriber IP traffic from WiFi to Internet.

Macro spectrum overload I though is a bigger consideration and off course
the use of cheaper access ..But, any ways as I'm saying split model is
fine and will be a dominant model.

Sri

On 5/20/13 12:24 AM, "Alper Yegin" <[email-masked]> wrote:

>If that were the case, then the operators wouldn't be offloading the
>subscriber IP traffic from WiFi to Internet.
>
>Alper
>

---

From: Peter McCann <[email-masked]>
Date: Mon, 20 May 2013 23:29:05 +0000

Hi, Sri,

Sri Gundavelli (sgundave) wrote:
>> centralization
> going through a central anchor and part of the other traffic breaking
> out locally is fine. My comment is not tie "cost" as the only argument
> for enabling LBO models. Its a deployment consideration that drives
> that decision. It may be about the availability of internet peering
> points, or many other considerations.

Agree cost is not the only argument for local break-out.  But it is an
important one and I think it's appropriate to call it out in a requirements
document.

>> LI should be a very small proportion of the traffic, and those flows
>> can be directed to a collection point as needed.
> 
> traffic. ? If its later, I assumed the Communication Content (CC) for
> intercept (in general) is HTTP+SMTP traffic which in most cases maps to
> 100% of the subscriber traffic.

I meant a small number of subscribers.

Besides, as far as I know RFC 2804 is still IETF consensus.  Unless you want
to re-open the Raven discussions, we should not even be considering LI requirements 
in our work in IETF, let alone allowing them to drive us to an architecture that is 
grossly inefficient.

-Pete

>> just because some small subset of the flow need it.  LI should be a
>> very small proportion of the traffic, and those flows can be directed
>> to a collection point as needed.  If you really need per-flow,
>> per-application charging, you can send meta-information about the flows
>> to a charging collection box.  No need to send the flows themselves.
>> 
>> -Pete
>> 
>> 
>>>> the Internet. Centralized solution: Take IP traffic from access
>>>> router to a core router to the Internet.
>>>> 
>>>>>>> false.  For  instance, if a centralized node requires 100
>>>>>>> units, and 100  distributed nodes each require 1.03 units, the
>>>>>> *both* at the edge node and also at the central node (and in
>>>>>> fact even in

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 21 May 2013 01:21:45 +0000

Hi Pete,

>important one and I think it's appropriate to call it out in a

Its fine. But, there is no data point to prove that one option is cheaper
than the other... :)

>in our work in IETF, let alone allowing them to drive us to an

I don't want to re-open RFC-2804 discussions, at least for now and surely
not in this WG. As I commented in OPSAWG some time back, I completely
disagree with that document and IETF's past views on this topic. It surely
needs a review to check its applicability and relevance for the current
times. To me its a regulatory requirement that operators need to comply
with, else they cannot deploy that service.

Now, in the DMM context, it is relevant when we justify models based on
such parameters such as cost ..etc. We cannot forget the key services and
draw some random conclusions. BTW, the cost argument may turn out to be
trueŠbut we have insufficient data here. Better approach would be to
consider both the options, but not make claims using "cost" as the driver.

Any case, my entry into this discussion was more with a general comment.
I'm not asking for any changes in the Reqs documentŠ

Regards
Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 29 May 2013 14:41:55 -0700

Hello Anthony,

I think the new text is worthwhile, but "increase" should
be "increases".

Regards,
Charlie P.

-- 
Regards,
Charlie P.