gmane.ietf.mext

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

Sri Gundavelli (sgundave — 2013-05-21T01:21:45

Hi Pete,


On 5/20/13 4:29 PM, "Peter McCann" <Peter.McCann-hv44wF8Li93QT0dZR+AlfA< at >public.gmane.org> wrote:




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





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

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

Peter McCann — 2013-05-20T23:29:05

Hi, Sri,

Sri Gundavelli (sgundave) wrote:

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.


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


>>>>>>

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

Sri Gundavelli (sgundave — 2013-05-20T17:29:53

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" <alper.yegin-FmLp16v9RAjYtjvyW6yDsg< at >public.gmane.org> wrote:

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

Sri Gundavelli (sgundave — 2013-05-20T17:27:26

Pete,


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.




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.McCann-hv44wF8Li93QT0dZR+AlfA< at >public.gmane.org> wrote:

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

Alper Yegin — 2013-05-20T07:24:41

On May 17, 2013, at 8:42 AM, Sri Gundavelli (sgundave) wrote:


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

Alper



>

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

h chan — 2013-05-18T04:47:28

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

How about revising PS3 to the following without 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-bounces-EgrivxUAwEY< at >public.gmane.org [mailto:dmm-bounces-EgrivxUAwEY< at >public.gmane.org] On Behalf Of KIM, BYOUNG-JO J (BYOUNG-JO)
Sent: Friday, May 17, 2013 9:24 AM
To: Peter McCann
Cc: dmm-EgrivxUAwEY< at >public.gmane.org
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Very much agre

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

h chan — 2013-05-17T21:07:12

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 m

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

KIM, BYOUNG-JO J (BYOUNG-JO — 2013-05-17T14:23:42

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:

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

Peter McCann — 2013-05-17T13:04:46

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:

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

Sri Gundavelli (sgundave — 2013-05-17T05:42:40





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.yegin-FmLp16v9RAjYtjvyW6yDsg< at >public.gmane.org> wrote:

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

Jouni Korhonen — 2013-05-02T08:56:25

Folks,

We have now got a number of reviews and specifically comments put into issue tracker. I am pleased to find out that the discussion on some of the posted comments has already started. 

The next thing is to solve the issues recorded in the issue tracker and close them one by one. Some of them are purely editorial. Some might need a bit more WG work. I encourage submitting intermediate version quite frequently once non-overlapping issues have been solved. That helps keeping track where we go.

The faster we get the document updates done, the better.. obviously.

- Jouni & Julien



On Apr 24, 2013, at 8:17 PM, Konstantinos Pentikousis <k.pentikousis-hv44wF8Li93QT0dZR+AlfA< at >public.gmane.org> wrote:

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

Seil Jeon — 2013-04-30T10:52:15

Hi Charlie,

Honestly, I don't know whether how it would be a feature or not. But I know
that the current multicast part is one of the requirements/considerations
the DMM should take into account. Actually, we need to think of the reason
why it is important. Existing approaches were a "patching-up" style that
first, base multicast support design has been made on the reference
protocol, then optimizations and extensions have been followed, thus leading
to the unnecessities to the reference protocol and the inefficiencies to the
network. I think this approach has been O.K. until now because IP mobility
support itself and enhancement for unicast has been first. But now I believe
we're in the slightly different stage when contemplating the ultimate goals
and expected effects by the DMM. So, I think we need to consider the
requirement reflecting such a concern at the initial stage. And current
multicast requirement does not prevent to appear 'good proposals' but only
provides the minimum guidelines of IP multicas

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

Alper Yegin — 2013-04-29T12:29:20

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:

Biggest Fake Conference in Computer Science

2013-04-27T17:06:31

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without

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

Charles E. Perkins — 2013-04-27T00:44:00

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:

Editorial suggestions for draft-ietf-dmm-requirements-03

Charles E. Perkins — 2013-04-27T00:19:22

Hello folks,

Here are some editorial suggestions for the document.

Check for missing articles.  For instance:
"Gateway selection mechanism"  -->  "A gateway selection mechanism"

"is also taking the"  -->  "also takes"

Delete "However" before "assigning".

Delete "Issues such as"

Delete "When demand exceeds capacity,"  or else explain why
the benefits are unavailable otherwise.

"In particular, there is an increase in direct communications among
    peers in the same geographical area."
           --> there has always been such locality... in fact maybe less
                 now than previously.  Otherwise, please provide a citation.

Delete "While deploying"

"today's mobile networks, service providers face"  -->
            "Today's mobile networks present service providers with"

Delete "more often than not,"

Delete "Therefore it is not uncommon to observe that"

"ever-increasing" -->  "unnecessary"

"provided"  -->  "managed"

"non-optimal"  -->  "unnecessary"

Delete "Given this motivational backgr

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

Charles E. Perkins — 2013-04-27T00:13:26

Hello Seil,

You suggest that if a feature is not listed as a requirement, it cannot be
considered during the evaluation of solution proposals.  This is not true.
Given the choice of two proposals, the one that meets the requirements
and offers the best other features will invariably be chosen.

The real danger is in disqualifying good proposals because they fail to
offer some feature that should not have been made into a requirement.
There is no harm in listing desirable features (like multicast) that would
enhance the value of a solution that meets the requirements.

Regards,
Charlie P.



On 4/26/2013 6:18 AM, Seil Jeon wrote:

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

Seil Jeon — 2013-04-26T13:18:26

Hi Charles,

Actually, in realizing DMM-based mobility management, as you know, they may
exist various ways or more requirements for DMM protocol deign tackling the
issues raised from CMM. Given the requirements defined in the document is
confining, in their ways, explicitly or implicitly the protocol design for
further steps.
It means that proposed solutions should satisfy or consider the
requirements, or they will not be DMM solution in DMM WG at least.

If you see the mail posted by Sergio a few days ago, the multicast part
title was changed with 'Multicast Considerations' for right meaning. With
the meaning, I think it would go together with the other requirements. Have
a look, please.


Regards,
Seil


-----Original Message-----
From: dmm-bounces-EgrivxUAwEY< at >public.gmane.org [mailto:dmm-bounces-EgrivxUAwEY< at >public.gmane.org] On Behalf Of
Charles E. Perkins
Sent: Thursday, April 25, 2013 1:24 AM
To: dmm-EgrivxUAwEY< at >public.gmane.org
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Hell

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

Alper Yegin — 2013-04-26T07:56:27

Hi Charlie,


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.




Alper

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

Charles E. Perkins — 2013-04-25T00:24:10

Hello again folks,

I can't type in all the editorial suggestions right now, but at least
I wanted to provide some overall comments that cause the
document to seem quite inaccurate in many of its claims.
Here are my general comments.

- The requirements need to be distinguished from the desirable features.
   For instance, section 4.7 describes a desirable feature, not a 
requirement.
   Moreover, the desirable feature may be unattainable.  This is important,
   because if feature is *required*, a solution not providing the *required*
   feature "must" be considered incomplete and rejected.

- The problem statement clauses should be located in an initial section.
   Each problem statement should have a motivation.

- There is no problem statement supporting sections 4.4 or 4.6

- There is no motivation for section 4.4

- There is nothing specific to DMM in sections 4.4 or 4.6

- Section 5 should cross-reference section 4.6, and they should both
   be rewritten to eliminate redundant extra verbiage of which t

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

Charles E. Perkins — 2013-04-24T21:14:30

Hello folks,

I have many editorial comments which I will submit later today.

However, I think the draft has a major organizational problem. Namely,
the "problem statements", instead of being properly collected together
in an initial section, are sprinkled in along with various statements of
requirements.

I remember there was previously a problem statement draft that
enumerated the PSs in the current requirements draft.  I think it is
O.K. (perhaps not optimal, but O.K.) for the problem statements to
be in the requirements draft, but not as currently situated.

This, along with the various other editorial clarifications that are
needed, lead me to believe that the draft is not yet ready, but I do
not think that there are major problems, and that the next draft
probably could be ready for advancement.

Regards,
Charlie P.