Subject: Re: [nemo] RO Problem snippets

From: "Fan Zhao" <[email-masked]>
Date: Thu, 7 Oct 2004 17:01:09 -0700 (PDT)

Dear Alex, 

I partially agree with you too. :-)
Please see the reply below.

Best regards,
fan

> Thierry Ernst wrote:
> >>>>> NEMO RO problem introduces more challenges and more 
> >>>>> difficulties than MIPv6 RO problem because of nested NEMO 
> >>>>> network
> >>> 
> >>> IMHO, as I understand the Network Mobility problem (i.e. mobility
> >>>  of a whole network managed by a single entity: the MR, and with
> >>>  the MNNs even unaware of the mobility - at least the LFNs), I 
> >>> think that the requirement of providing such a (optimised) 
> >>> solution that maintains this transparency to the MNNs is also 
> >>> challenging. I'm not saying that the RO solutions based on 
> >>> NEMO-aware MNNs are not valid, but that one of the key 
> >>> differenced between Network Mobility and Terminal Mobility IMHO 
> >>> is that the nodes that are actually moving can be totally unaware
> >>>  of the movement (and that those nodes should profit of some 
> >>> route optimisation if possible).
> >> 
> >> So it is a requirement Rx that a NEMO RO solution still allows for
> >>  LFN's to not be mobility aware.
> > 
> > Back to my the last 2 mails, I suggest to list this (call it 
> > "mobility transparency for MNNs" or "NEMO-enabled") as one of the 
> > metric/qualifier to evaluate which proposition qualifies or not for a
> >  solution.  We can only decide which is our degree of tolerance for 
> > each qualifier when we have a good view of the potential solutions.
> 
> Thierry, partially ahree.  Let me say just the not part.  I don't think
> we need to metricize/qualify/classify/evaluate solutions.  I think the
> Generic RO Model draft and the taxonomy already have large parts that
> generalize and qualify the solutions.
>
Whether a solution meets the requirement or not is a high (maybe coarse) 
level of evaluation while the metrics part provides a way to
evaluate how well a solution meets the requirement (Among all the 
solutions that meets the requirements, one may be better in some aspects
 but short in others.), which is closer to
the requirement draft rather than taxonomy draft. We can also 
assign the weight/cost to each metric/qualifer. The solution should be 
overall the best in the different configurations and
 mobile scenarios.

> I think we need to define the problem in the problem statement draft.
> That could be as short as 5 pages.
> 
> I think we should turn all explanations of solutions as support of the
> problem itself, not as precursors of requirements, or as evaluators
> which decide which RO solution is best.
> 
The requirement has to be defined before the solution. 

> For example, one way that it could be written is: "The problem is that
> paths are very long.  Some NEMO RO mechanisms propose that MR updates
> the CN's BC not only with its CoA but with its MNP too.  This however
> involves a security risk regarding all hosts with addresses configured
> from that prefix.  To avoid these risks, the MR may use RR tests for
> each address in the MNP; this behaviour is not feasible due to large
> number of full 128bit addresses possible out of a 64bit prefix..."  This
> leaves us with a standing problem, and not with a selected solution.
> 
> Better yet: the problem is that the paths are very long.  To find
> optimal paths, some mechanisms propose to: (1) send route updates to AR
> but this is not feasible because, (2) send MNP to CN but this is not
> feasible because, (3) send XYZ to ZYX but this is not feasible because.
> 
> I do not think that the problem statement draft should contain a
> reasoning like: RO mechanism 1 offers mobility transparency and no
> security, while RO mechanism 2 offers security with no secrecy
> transparency, so we prefer mechanism 1.  It is much too early for this.
>
I agree. 
 
> Alex

---

From: "Fan Zhao" <[email-masked]>
Date: Thu, 7 Oct 2004 21:54:51 -0700 (PDT)

Dear Thierry,

I completely agree with you.
BTW should all three topics be included in
one draft or in different drafts?

Best regrads,
fan
  
> 
> Hi,
> 
> Alexandru Petrescu <[email-masked]> wrote:
> > Thierry Ernst wrote:
> I propose something more synthetical, but I don't see the motivation of
> your opposition ("because there is already attempts to do so in
> drafts"). Well, we are discussing about what the WG document should
> content, aren't we ?
> 
> I think that's also going too much into the analysis of the solutions.
> The only way to do this from the perspective of the solutions is to
> build a (complete) taxonomy of the solutions (what Thubert's draft
> attempts at doing) but the problem here is that the taxonomy can only
> include already made solutions. Better solutions may come later, once
> the problem is well-known for everyone ... 
> 
> So, I think that the analysis of the solution space can only start once
> we have realized the following 3 steps, in this order:
> 
> 1. the problem (where routing is not optmized, why, what is the cause
> and consequence [packet overhead, longer dely, ...]
> 
> 2. the design goals (mimimal overhead, minimal delay, minimal number of
> "mobility  hops", ...)
> 
> 3. metrics/qualifiers
> 
> 
> Definitely agree with this.
> 
> Thierry.
> 
>

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 8 Oct 2004 08:09:29 +0200

> one draft or in different drafts?

Agreed too. My view of this:

In terms of papers, we do not necessarily have to decide right now. I
understand that 1 comes first anyway. 2 and 3 seem to come together, but
later. So let's focus on 1 for the time being. The taxonomy draft aimed
at helping the thought process for this by making categories.

Alex made a constructive summary (his snippets, sorry I still need to
respond to that) from various drafts including the taxonomy one, proving
that the drafts were useful for the problem statement. I hope that the
drafts will be useful again when it comes to goals and finally when we
elaborate solutions.

I do agree that the problem part (your 1) must be concise and should not
qualify the problems but just list them (like one liners again). Then
the goals should order the needs for fixing the problems (relative
importance, which ones are mandatory etc... a form of qualification
actually). Then the metrics would be defined for each problem to help
quantify the solutions and define what's acceptable, what's not.

Pascal

Pascal

---

From: "Fan Zhao" <[email-masked]>
Date: Fri, 8 Oct 2004 00:14:36 -0700 (PDT)

Dear Psacal,

Thanks for your reply. Please see my reply below.

Best regards,
fan
 
> I do agree that the problem part (your 1) must be concise 
IMO, "concise" is definitely not the most important requirement
 of "problem" part if it is one of requirements. The problem part 
intends to analysis the NEMO RO problem in depth, inspires and provides 
guidence to design a good NEMO RO soltuion. The problem part must 
not be solution-specific; instead, it should be in a general and 
abstract way. Why concise is important?  

> and should not qualify the problems 
> but just list them (like one liners again). Then
> actually). 

> Then the metrics would be defined for each problem to help
Why are the metrics defined for each problem? Do you mean that 
some metrics are only specific to a certain kind of problem?

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 8 Oct 2004 09:35:17 +0200

Hi Fan:)

> abstract way. Why concise is important?

I think the problems must be clear cut and if they are well understood,
then we should be able to present them in one line. Just like Thierry
did so well for the requirements. Then it's the role of the ML to debate
how each problem should be approached, taking them per order of
importance, and rating the solutions per the metrics we define to
finally make a decision. Note that we'll need re-chartering in between.

The archives of the ML can contain all that debate. But the paper making
RFC must be factual: even saying that the solution should be like this
or like that would cause endless discussions and the draft would never
make it through.

> some metrics are only specific to a certain kind of problem?

Not all the problems have the same nature, so the same metric does not
necessarily apply. You can not mesure security problems (like a degree
of privacy, how many people know where I am, every body, just my HA?)
and packet overhead for instance.

Pascal