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

From: "Fan Zhao" <[email-masked]>
Date: Sun, 14 Nov 2004 03:28:13 -0800 (PST)

Hi Chan-Wah,

I am sorry I would like to readdress the BU storm issue. 
Please see below.

Sincerely,
fan
> > > 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.
The words above only assume the situation where the nested network is 
formed in a short period. I realize that when one intermediate MR moves, 
there is no such BU storm in the NEMO basic support. So let me put it in 
this way, BU storm is a potential problem that a RO solution may have;
a similar phenomenon may also happen when the nested NEMO network is
 formed in a very short period (note that either in RO or nemo basic
 support, MR has to wait until the upstream MR finishes the BU 
procedure.). The text in draft-taxonomy compares the signal overhead 
with the data traffic overhead, I think it is not necessary, the
signal overhead must have to be reduced if possible no matter the volume
of data traffic.

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 16 Nov 2004 10:19:29 +0100

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: lundi 15 novembre 2004 14:55
> To: Pascal Thubert (pthubert)
> Cc: T.J.Kniveton; [email-masked]; Chan-Wah NG
> Subject: Re: [nemo] comments on solution space analysis part in
taxonomy draft
> 
> Pascal Thubert (pthubert) wrote:
> >>Section 3.2 Infrastructure Optimization fails to mention BGP.  But
it
> >>does mention HAHA as a potential Infrastructure Optimization (to my
> >>understanding, HAHA is _not_ known to work even on paper, so why
> >>mentioning it at all).
> >
> > Do you mean that mobility should interfere with BGP in the infra
> 
> I don't mean that BGP should interfere with mobility.  I don't comment
> on a kind of solution or what should be done.  I just mean that
optimal
> paths can be obtained by injecting routes (and not use Mobile IP).  I
> also mean that using routes directly can not scale to the size of the
> bigger Internet, but can work ok within small domains.
> 
> I also refer to a BGP for NEMO presentation which I've seen slides on
> the web and to which I've already sent an URL.  And also refer to some
> BGP discussion that happened here earlier.

Agreed; there is no reason the RESTRICT the usage of NEMO when we can
avoid it. Also, some changes in BGP might be useful that would not cause
leakage in runtime as the MR moves.

Also, in some cases, we might use BGP to link NEMOs as well as opposed
to grow a single, larger NEMO, which could become unmanageable. This
might be seen as a MANET problem, but it's something that we could
benefit from.

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 17 Nov 2004 12:10:09 +0100

Dear Fan:

> > 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.

I will not take that argument. I could try to accept the exclusiveness
theory, but completeness seems hard to prove. We rely on the WG to pop
up with anything we could have missed. EG Thierry's PhD on multicast BU
(Sorry Thierry:) .

This is not an academic exercise, either. We chose to trade a bit of
redundancy for the sake of clarity. We have a limited overlap with the
classification by applicability. Maybe it's better then holes. 

Pascal

---

From: "Fan Zhao" <[email-masked]>
Date: Thu, 18 Nov 2004 13:53:11 -0800 (PST)

Hi Chan-Wah,

> On Sun, 2004-11-14 at 02:37 -0800, Fan Zhao wrote:
> > > 
> > > > "  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. 
> 
> 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.
>
Sorry for the misunderstanding.
 
> >  
> > > > 
> > > > "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"
> > 
> 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.
>
OK. 
> 
> > > > "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.
> 
> 
> > > problem statement?  Why?  It is not a problem of NEMO Basic 
Support.  It
reduce 
NEMO 
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?
> 
Yes, I agree that "BU_Storm" is an issue of RO solution. 

> > > 
> > > 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.
> > > 
example to the solution space, making it more complete everytime I do 
that.
> /rgds
> /cwng

---

From: "Fan Zhao" <[email-masked]>
Date: Thu, 18 Nov 2004 14:07:54 -0800 (PST)

Hello Ryuji,

Thanks for your reply. Please see below. Thanks.

Sincerely,
fan

> 
> Hi Fan
> 
> At Sun, 14 Nov 2004 02:37:41 -0800 (PST),
> Fan Zhao wrote:
> 
> <snip>
> 
> > > > 
Optimization"
categorize 
same 
(which
are
MNN.
between 
the 
context of 
> > NEMO RO.
> 
> 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.  
>
Yes, the content of binding information is different.
 
> But I agree with Fan that the text in the draft is very solution 
specific.
party
infrastructure.
> I believe Pascal wanted to classify whether end nodes involve RO 
procedure or not :-)
OK.
 
> 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. 
>
I think I misunderstand what the "approach" means before.
But it might be necessary to point out what types of "approaches" 
are needed to form a "solution" to solve the whole NEMO RO problem.
 
Support.  It
reduce 
NEMO 
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.
>
OK, I agree.
 
> regards,
> ryuji