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

From: "Fan Zhao" <[email-masked]>
Date: Sun, 14 Nov 2004 02:37:41 -0800 (PST)

Hello, Chan-Wah,

> On Thu, 2004-11-11 at 23:09 -0800, Fan Zhao wrote:
> > 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.
> > 
> 
> Sure, we could have just created a new "benefits of RO" section.
OK.

> 
> > "  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.
> 
> 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.
>
It is fine with me if you want to write your draft as a survey. But IMHO,
the NEMO RO peoblem WG document should not be just a survey. The analysis
of the complete solution space is one of the key values of this WG 
document. 
 
> > 
> > "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.
> > 
> 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.
>
1) The idea of these two is to distribute the binding information between 
HoA and MNP/CoA to CN. Although they extend the MIP6 RO procedure in the 
different ways, these kind of differences are secondary in the context of 
NEMO RO.
2) You want to "describe the solution space of route optimization by
   listing different types of approach to route optimization."
So your approach listed in this sub-section has to solve the problem you 
describe in the problem statement part. However, I do not see 
how "Binding Update with Network Prefix" and "MR as a Proxy" solve the 
problem completely including in the nested NEMO and intra-NEMO cases. Do 
you agree?
3) I can immediately come up with two "MR-to-CN optimization" approaches:
3.1 MR does not send CoTi and HoTi on behalf of the MNN, instead it 
intercepts the CoTi and HoTi sent by the MNN and changes the source IP 
address in CoTi into its CoA. The rest is as same as in "MR as a proxy"

3.2 MR sends a probing packet in the outbound direction to collect the 
full path information to the Internet. The information about the upstream 
router is either recorded in the reply message or carried by each 
individual message like traceroute. Finally MR registers this information 
with CN. What do you think?
 
> > "Infrastructure Optimization" I do not understand why "MR-to-CN 
> > optimization" does not
> > possibly fall into this category. 
> > 
> 
> Because it doesn't.  Infrastructure optimization means some third party
> entity in the infrastructure takes part in the optimization.
>
So you'd better change the title. Because you list "Infrastructure 
Optimization" and "MR-to-CN optimization" in parallel, the reader may 
wonder why the path between MR and CN may not be in the infrastructure.
And again, the approach under this section does not solve the NEMO RO 
problem completely.

> > "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.
> > 
> 
> 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?
>
As I describe before, MR sends a probing packet to collect the full path 
information to the Internet and registers it with CN, thus the data 
packet only carries the information in the routing header alike payload 
without tunnel. Does it fit into this category or MR-to-CN category?

Since you list "MR-to-CN optimization", "Infrastructure Optimization" 
and "Nested Tunnels Optimization" in parallel, what is the criterion you 
used to differentiate the approaches into different types?

And again, the approach under this section does not solve the NEMO RO 
problem completely.
 
> > "MIPv6-over-NEMO Optimization" 
> > A lot of duplications for me.
> > 
> 
> Perhaps.
>
OK.
 
> 
> > 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. 
> > 
> 
> True, that's an area where we can supplement each other.
>
OK.
 
> 
> > 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.
> > 
> 
> problem statement?  Why?  It is not a problem of NEMO Basic Support.  It
> is a potential problem certain RO approaches might face.
>
If you look into the problem closely, the number of BU packets in NEMO 
basic support is as same as in the NEMO RO if no method is used to reduce 
the number of BU packets. If this is not the problem of NEMO basic 
support, why it can become the problem in NEMO RO? So originally in NEMO 
basic support protocol the number of BU packets can not be reduced, but 
NEMO RO can look into this problem and find a way to reduce the overhead.
 
> > 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.
> 
> Thank you for pointing out that, I will reflect that on the next update.
>
OK. 

> 
> > 
> > 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?
> > 
> 
> 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 understand what you mean. But just be careful to use the term 
accurately.

> 
> > 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.
> > 
> 
> 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.
>
OK. 
> 
> > 4.1.5  Other Considerations
> > If you think they are not "tradeoff", they should not be under this 
> > section.
> > 
> 
> Why not?  I did not say section 4.1 is a trade-off discussion section.
> 
So this is a cost discussion section? Sorry I am so confused.
"one would expect the costs described in the following sub-sections to be 
incurred."
"Additional Signaling Overhead" "Increased Protocol Complexity"
"Mobility Awareness ?" "New Functionalities ?" "Compatibility with NEMO 
Basic Support?" "In-Plane Signaling versus Off-Plane Signaling ?"
 
> 
> > 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.
> 
> You applied too strictly an interpretation of the meaning of
> "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.
> 
> 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.
>
OK. 
> > There are a lot of redundency too because of the way the draft used 
to 
> > categorize the
> >  solution space.
> 
> 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 am working on it.
 
> >  I prefer a general security consideration also.
> > 
> 
> Me too, and I have already promised a general security consideration
> section in my previous posts.
> 
> > Overall, the solution space part does not analyze the space 
completely and
> > 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.
> 
How can you prove the completeness?

> /rgds
> /cwng

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 17 Nov 2004 17:34:26 +0800

> of the complete solution space is one of the key values of this WG 

You are now putting words into my mouth.  No, i mean the appendix (and
not the whole draft) is a review of the current state of RO solutions.

> address in CoTi into its CoA. The rest is as same as in "MR as a proxy"
Agree, the part on MR as a Proxy is too detailed, (and the weak reason I
offer is due to the short time from the idea popping up in the ML to the
submission deadline).  It will be changed in the next version.

> NEMO RO can look into this problem and find a way to reduce the overhead.

I asaw you've retracted your objection in another mail.  SO does this
means that you agree BU_Storm should be an "issue" of RO solution,
rather than a "problem " of NEMO Basic Support?

> How can you prove the completeness?

I don't.  I disprove it by counter-example, and then add that counter example to the solution space, making it more complete everytime I do that.

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Nov 2004 17:04:24 +0100

Chan-Wah NG wrote:
> submission deadline).

There was long discussion about how LFN would "delegate trust" to MR to 
do such RO operations on its behalf, check
http://www.mobilenetworks.org/nemo/archives/monet-arch-feb02-oct02.txt
and search for "delegation", or "trust delegation".

Alex

---

From: Chan-Wah NG <[email-masked]>
Date: Thu, 18 Nov 2004 00:42:31 +0800

> and search for "delegation", or "trust delegation".

Okay, Alex, now you blast my weak reason/excuse to oblivion! :)  Yep, I
admit it was negligence on my part for deciding to write on the MR as a
proxy approach the taxonomy very near the deadline, and Erik's summary
was so much easier to "extract" than the whole thread on trust
delegation ...

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Nov 2004 17:50:55 +0100

Chan-Wah NG wrote:
>>> Agree, the part on MR as a Proxy is too detailed, (and the weak
>>> reason I offer is due to the short time from the idea popping up
>>> in the ML to the submission deadline).
>> 
>> There was long discussion about how LFN would "delegate trust" to
>> MR to do such RO operations on its behalf, check 
> Okay, Alex, now you blast my weak reason/excuse to oblivion! :)

No no!  Just to say that if you need more on this particular topic maybe
there could be found some... no intention to blast whatever! :-)

> Yep, I admit it was negligence on my part for deciding to write on
> the MR as a proxy approach the taxonomy very near the deadline, and
> Erik's summary was so much easier to "extract" than the whole thread
> on trust delegation ...

That is right, and in addition there should be mention somewhere that MR 
doing RO on behalf of LFN means that LFN trust somehow MR to do so.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 18 Nov 2004 09:01:21 +0900

Hi Fan

At Sun, 14 Nov 2004 02:37:41 -0800 (PST),
Fan Zhao wrote:

<snip>

> different ways, these kind of differences are secondary in the context of 

In the case of "MR as a Proxy", MR sends MNN-address and MR-CoA (not
HoA/MNP/CoA) to CN as a MIP binding.  Binding information registering
to CN is different.  

But I agree with Fan that the text in the draft is very solution specific.

> And again, the approach under this section does not solve the NEMO RO 

I believe Pascal wanted to classify whether end nodes involve RO procedure or not :-)

What do you mean the approach does not solve the NEMO RO completely?
These approaches may not solve RO issues completely, but they improve
NEMO performance in certain level. It is very important to know which
approach can solve which issue.  With knowing possible approaches, we
can judge whether WG needs the approach or not. 

> NEMO RO can look into this problem and find a way to reduce the overhead.

I can not get your point.
In the NEMO basic, MR sends single BU to HA. 
If MR decided to send BU to CNs, #of BU is increased as #of CNs.

regards,
ryuji

---

From: Masafumi Watari <[email-masked]>
Date: Thu, 18 Nov 2004 23:40:56 +0900 (JST)

Hi Fan, Chang-Wah

On Sun, 14 Nov 2004 02:37:41 -0800 (PST),

> used to differentiate the approaches into different types?

I agree with Fan on this.  Nested Tunnel optimization should not be
listed parallel with the other optimization, since they are different
problems.  I don't see how you catagorized these, and they were hard
to read.

For example, reading the text for "MR-to CN optimization", you must be
assuming that CNs are located at the infrastructure, right?  Wouldn't
they involve other solutions if the CN is also nested?

watari