Hello Anthony,
I think the new text is worthwhile, but "increase" should
be "increases".
Regards,
Charlie P.
On 5/17/2013 2:07 PM, h chan wrote:
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: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of KIM,
BYOUNG-JO J (BYOUNG-JO)
Sent: Friday, May 17, 2013 9:24 AM
To: Peter McCann
Cc: dmm@ietf.org
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
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/
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
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
_______________________________________________
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
--
Regards,
Charlie P.
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
