Subject: [nemo] comments on solution space analysis part in taxonomy draft

From: "Fan Zhao" <[email-masked]>
Date: Thu, 11 Nov 2004 23:09:20 -0800 (PST)

Dear Pascal and Chan-Wah,

I have some comments on the draft-thubert-nemo-ro-taxonomy-03. 
I will focus on solution space analysis part as we already have 
discussed on the problem statement part before.

Section 3. Solution Space of NEMO Route Optimization
"Shorter Delay", "Reduced Consumption of Overall Network Resources",
"Less Susceptibility to Link Failure", "Greater Data Efficiency"
are the benefits of RO, which should be in the problem statement part, 
but not
in the solution space analysis part.

"  There are multiple proposals for providing various forms of route
   optimizations for NEMO (see Appendix A).  "
Please delete the appendix. As some proposals are incomplete, even some
does not work. What's more, some proposals look different but actually 
using
the same core idea.

"3.1  MR-to-CN Optimization" "3.2  Infrastructure Optimization"
"3.3  Nested Tunnels Optimization" "3.4  MIPv6-over-NEMO Optimization"
"3.5  Intra-NEMO Optimization"
The solution space analysis part is organized like in the problem 
statement part
to me. I do not see any logic behind the way you use to categorize the 
solution space.
Remember that the different problem scenarios do not mean the different 
solutions (core ideas). 

"Binding Update with Network Prefix" and "MR as a Proxy" use the same 
idea to me and are
described in a too specific way.

"Infrastructure Optimization" I do not understand why "MR-to-CN 
optimization" does not
possibly fall into this category. 

"Nested Tunnels Optimization" 
"Nested tunnels" is not the core of nemo ro problem and it
sounds too specific too. It could make one reader wonder why other tunnel-
reduction
methods are not listed.

"MIPv6-over-NEMO Optimization" 
A lot of duplications for me.

4.  Analysis of Solution Space
 
4.1  General Considerations of RO Solution 
The content describes the tradeoffs similar with the section of "the 
related tradeoffs" 
in the draft-zhao-nemo-ro-ps-00.txt. :-) Our draft also has other 
tradeoffs. 

4.1.1  Additional Signaling Overhead
The text of BU sould specific to me. The text of BU storm should belong 
to problem statement
part.

4.1.2  Increased Protocol Complexity
I understand your point. However it seems to me the scalability issue has 
more impacts on
 power and processing resources than the protocol complexity.

4.1.3  Mobility Awareness
"it will be difficult for mobile network nodes to control the decision of 
having 
this tradeoff" 

Is that also the case for VMN?

4.1.4  New Functionalities
"Correspondent Nodes
      It is generally undesirable for correspondent nodes to be required
      to implement new functionalities."

I do not agree. It depends on the type of CN.

4.1.5  Other Considerations
If you think they are not "tradeoff", they should not be under this 
section.

4.2  Specific Types of RO Solution
"Many of the tradeoffs discussed previously in Section 4.2 are
   dependent on the actual route optimization approach."
Please give an example that one solution does not have one of the 
tradeoffs above.
If there is one, your discussion about tradeoff is not general.

Some text seems like a evaluation to me. I recall one email on the ML 
before
states that the problem draft should not judge on the quality of the 
solution.
There are a lot of redundency too because of the way the draft used to 
categorize the
 solution space. I prefer a general security consideration also.

Overall, the solution space part does not analyze the space completely and
does not categorize the solution space into mutual exclusive categories. 
My personal oponion is that this draft needs some fundmental changes Thus 
I agree
that WG should work on a new WG document based on the existing documents 
in order to be more productive. 

Sincerely,
fan

---

From: Chan-Wah NG <[email-masked]>
Date: Fri, 12 Nov 2004 19:54:49 +0800

> in the solution space analysis part.

Sure, we could have just created a new "benefits of RO" section.

> does not work. What's more, some proposals look different but actually 

Perhaps, but that is not up to us to judge.  The readers have to decide
for themselves whether the individual proposals work or not.  An
appendix is an appendix.  It is something that you could do without.  I
view the work done on ro-taxonomy-03.txt as a survey/review of what is
the current state of RO solutions, and it felt incomplete without
reference to all the proposals that have been made.

> described in a too specific way.
Same idea?  Are you sure?  They may be solving the same problem (which
is why we put them into the same "MR-to-CN"  optimization, but they are
entirely different.  The former requires the MR to send prefix
information to CN, the latter requires the MR to pretend to be the MNN.
The core idea is quite different to me.

> possibly fall into this category. 

Because it doesn't.  Infrastructure optimization means some third party
entity in the infrastructure takes part in the optimization.

> sounds too specific too. It could make one reader wonder why other tunnel-

Nested tunnel optimization is to reduce tunnel ... what other
tunnel-reduction method you have in mind that does not fit into the
descriptions of nested tunnel optimizations?

> A lot of duplications for me.

Perhaps.

> in the draft-zhao-nemo-ro-ps-00.txt. :-) Our draft also has other 

True, that's an area where we can supplement each other.

> The text of BU sould specific to me. The text of BU storm should belong 

problem statement?  Why?  It is not a problem of NEMO Basic Support.  It
is a potential problem certain RO approaches might face.

>  power and processing resources than the protocol complexity.

Thank you for pointing out that, I will reflect that on the next update.

> Is that also the case for VMN?

Now you are going into approach specific area.  In the general
considerations, we just list out issues that in general an approach
might have to overcome.

> I do not agree. It depends on the type of CN.

Perhaps.  I tend to believe that the statement reflect what most people
feel.  I might update the text to show that it depends on the type of
CN.

> If you think they are not "tradeoff", they should not be under this 

Why not?  I did not say section 4.1 is a trade-off discussion section.

> If there is one, your discussion about tradeoff is not general.

You applied too strictly an interpretation of the meaning of
"general".  

> states that the problem draft should not judge on the quality of the 

Perhaps, I am sorry if I give the impression of 'judging the quality of
the' approach (again, I prefer to use the term approach rather than
solution).  It is not my intention.

> There are a lot of redundency too because of the way the draft used to 

Perhaps, but I would like to see a different categorization that is (a)
mutually exclusive, (b) complete, and (c) useful.   For me, the prioirty
is in the revese order ... a catgorization scheme should first be
useful, and then strive to be complete, and finally preferably with
minimal duplication.

>  I prefer a general security consideration also.
> 

Me too, and I have already promised a general security consideration
section in my previous posts.

> does not categorize the solution space into mutual exclusive categories. 

As I've mentioned, I strive to be complete, and not mutually exclusive.
My feeling is that we are very close to a complete description, once we
feel in the parts on MANET as an RO appraoch.

/rgds
/cwng