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" <peter.mcc...@huawei.com> 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" <alper.ye...@yegin.org> 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 >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Charlie P. >>>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
