Re: WGLC #2 starts for draft-ietf-dmm-requirements-03

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







On 5/17/13 6:04 AM, "Peter McCann" <[email protected]> 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
>
>
>Sri Gundavelli (sgundave) wrote:
>> 
>>> 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 protected]> 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 protected]
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Regards,
>>>> Charlie P.
>>>> 
>>> 
>>> _______________________________________________
>>> dmm mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/dmm
>> 
>> _______________________________________________
>> dmm mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm
>
>
>