Hi, Sri, Sri Gundavelli (sgundave) wrote: > 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.
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. > > 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. 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 > > > > 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
