Subject: [nemo] More comments on draft-thubert-nemo-ro-taxonomy-04

From: Thierry Ernst <[email-masked]>
Date: Tue, 8 Mar 2005 15:14:25 +0900

Dear draft authors,

Here are a couple more comments on the draft. I think it has reached a
very good quality.

I wonder if it would be possible (or reasonable) to have some
considerations for multihomed configurations (of course, that may be too
complex to deal with this in this draft).

1.  Introduction

   With current Network Mobility (NEMO) Basic Support [1], all
   communications to and from nodes in a mobile network must go through
   the bi-directional tunnel established between the Mobile Router (MR)
   and its Home Agent (HA) when the mobile network is away.  Although
   such an arrangement allows Mobile Network Nodes (MNNs) to reach and
   be reached by any node on the Internet, there are associated
   limitations which might be unacceptable for certain applications.  In
   particular, voice over IP has strict requirements on packet jotter

jitter

   To such end, this document first describes the problem of Route
   Optimization in NEMO in Section 2.  Next, Section 3 discusses the
   benefits route optimization might bring to NEMO.  Follwing this,

following

2.  Problem Statement of NEMO Route Optimization

   Readers might be interested to note the availability of [6] which
   also discusses the problem statement of NEMO Route Optimization.

There were 2 other drafts, [7] and draft-clausen.

2.1  Sub-Optimality with NEMO Basic Support

   With NEMO Basic Support, all packets sent between a Mobile Network
   Node and its Correspondent Node are forwarded through the MR-HA
   tunnel.  This results in a sub-optimal routing, also known as
   "dog-leg routing", with NEMO Basic Support.  This sub-optimality has
   the following undesirable effects:

May be it is useful to recall what "dog-leg routing" is (or isn't it
better to use another term, like pin-ball routing or to simply remove
this sentence since the description of the issue is written in "longer
route" ?

   o  Increased chances of packet fragmentation

      The increased in packet size due to packet encapsulation may

"The increased packet size" or "The increase in the packet size ..."

2.3  MIPv6 Host in Mobile Networks

   When a MIPv6 mobile node joins a mobile network, it becomes a
   Visiting Mobile Node (VMN) of the mobile network.  Packets sent to
   and from the Visiting Mobile Node will have to be routed not only to
   the Home Agent of the Visiting Mobile Node, but also to the Home
   Agent of the Mobile Router in the mobile network.  This suffers the
   same amplification effect of nested Mobile Router mentioned in
   Section 2.2.

Well, if this is a VMN and if packet must be routed to the home agent of
the VMN, it means it operates MIP6. So, why would the packet be sent to
the VMN's HA ?

I think the paragraph below and the one that follows could be grouped.

3.  Benefits of NEMO Route Optimization

Actually, isn't it straight forward form the list of issues in the
precedent section ? I mean, for instance, if the issue is "larger
delay", solving the necessarily means "shorter delay". 

So, 2 and 3 may be indeed redundant. 

4.1  MR-to-CN Optimization

   o  Binding Update with Network Prefix

      This approach is particularly useful when a lot of MNNs in a
      mobile network is communicating with a few corresponding nodes.
      In such cases, a single Binding Update can optimize the routes of
      many flows between the Correspondent Node and the MNNs.

can => would

4.3  Nested Tunnels Optimization

   o  Mobile Home

      This model applies to a category of problems where the mobile
      networks share a same administration and consistently move
      together (e.g.  a fleet at sea).  In this model, there is a
      cascade of Home Agents.  The main Home Agent is fixed in the
      infrastructure, and advertises an aggregated view of all the
      mobile networks.  This aggregation is actually divided over a
      number of mobile routers, the root-MRs.  The root-MRs subdivide
      some of their address space to the other Mobile Routers forming
      their fleet, for which they are Home Agent.  As Home Agents, the

I don't understand how the root-MR becomes a HA.

   o  MANET Routing

top-level Mobile Router: I would use root-MR, to keep consistency with
other sections (also, we have agreed to deprecate this term).
ub-sections to be incurred.

5.2  Increased Protocol Complexity

   Some nodes will be required to have additional functionalities in
   order to incorporate NEMO Extended Support.  This increases the node
   complexity.  It may not be feasible to implement new functionalities
   on legacy nodes.  If such nodes are mobile, this may prove to be a
   significant cost	due to the limited memory resources such devices
   usually have.

such nodes: is this the "legacy nodes" in the sentence before, or is
this related to "Some nodes" at the beginning of the paragraph ?

5.5  Other Considerations

   o  Compatibility with NEMO Basic Support

      It will be beneficial to vendors if a route optimized solution for
      NEMO is compatible with NEMO Basic Support.  This reduces the
      complexity and achieves greater reuse of existing functionalities.

I think it MUST be compatible with NEMO BS, if we assume NEMO BS as the
backup mechanisms to provide for session continuity.

6.  Analysis of Solution Space

   o  Binding Update Storm

      If the Mobile Network Nodes in a mobile network are communicating
      with a lot of Correspondent Nodes, whenever the Mobile Router
      changes its point of attachment, it needs to send out a large
      number of binding updates to Correspondent Nodes.  This is further
      worsen by the fact that the Mobile Router has to perform the
      return routability procedure prior to sending binding updates.

See my earlier mail: there are are also the periodic BUs that must be
sent to refresh binding caches.

6.3  Nested Tunnels Optimization

   o  Binding Update Storm

      Depending on the specifics of a solution for nested tunnels
      optimization, the upstream information may be the care-of address
      of the upstream Mobile Router.  This will leads to the a burst of
      Binding Update messages whenever an upstream Mobile Router changes
      its point of attachment, since all its sub-MRs must send binding
      updates to their Home Agents to update the new upstream
      information.

How does it compare with solutions x.1, x.2 where BUs are sent to CNs (I
think in the present case BUs are not sent to CNs) ? Wouldn't it be
better to speak about "Signaling Overhead" ?

6.4  MIPv6-over-NEMO Optimization

   o  Mobility Awareness

      The Visiting Mobile Node will need to acquire the upstream
      information, most likely including the mobility and location
      information of the upstream Mobile Routers.

Is this an issues for a VMN ? Isn't it always the case for a MIP6 node
and couldn't it be considered as "normal" ?

   o  Processing Burden

      This approach also increases the processing burden of the Mobile
      Router, as it needs to maintain information necessary for Route
      Optimization to work for every Correspondent Node that is
      communicating with each visiting mobile node.  This may not scale
      very well when one consider, for example, a train network, where
      there are hundreds of Visiting Mobile Nodes in one mobile network.

What about BU storm (or signaling overhead, if you prefer) ?

9.  References

   [7]   Ernst, T., "Route Optimization with Nested Correspondent
         Nodes", Internet-Draft draft-watari-nemo-nested-cn-00, October
         2004.

Watari is the first author. I don't know how the IETF secretariat comes
to mix this up in the draft announcement.

Thierry

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 09 Mar 2005 03:42:22 +0800

Hello Thierry,

thank you for your extensive comments.  See (some) responses in-line.

/rgds
/cwng

> complex to deal with this in this draft).
It was actually in a previous incarnation of the draft, however, we feel
it may be a bit premature (and certainly complex) to include multihoming
considerations.

> this sentence since the description of the issue is written in "longer

It is a terminology issue.  I will check what is the more prevailing
terminology.  (PS, Is there any related terms defined in
draft-ietf-nemo-terminology?)

> the VMN, it means it operates MIP6. So, why would the packet be sent to

Sorry, I don't quite catch your question.  Is there a typo somewhere in
your question?

> So, 2 and 3 may be indeed redundant. 
Perhaps, unless someone comes up with a side effect of RO that is
actually beneficial :)

> ub-sections to be incurred.

Agreed.

> this related to "Some nodes" at the beginning of the paragraph ?
Ok, "such nodes" = "Some nodes" .  will clear this up.

> backup mechanisms to provide for session continuity.

Perhaps compatible is not such a good word.  What I am thinking when I
wrote that paragraph was more like "similarity" instead of
"compatibility".

> sent to refresh binding caches.

Of-course.

> better to speak about "Signaling Overhead" ?

Agree, a signalling storm is the more general (and perhaps accurate)
term.

> and couldn't it be considered as "normal" ?

Huh?  No, current specs in RFC 3775 does not require a MIPv6 in a Mobile
Network to know any information about the MR.

> What about BU storm (or signaling overhead, if you prefer) ?

Of-ourse.  BU (or signalling) storm is a issue for almost all types of
approach, and hence is not repeated in analysis of every specific
approach.

> to mix this up in the draft announcement.

Sorry, but blame it on the xml depository :)

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 9 Mar 2005 05:07:23 +0900

Hi,

> > better to use another term, like pin-ball routing or to simply
> > remove this sentence since the description of the issue is written
> > in "longer route" ?
> 

No, and neither in RFC 3753 which I just checked.

> >    Visiting Mobile Node (VMN) of the mobile network.  Packets sent
> >    to and from the Visiting Mobile Node will have to be routed not
> >    only to the Home Agent of the Visiting Mobile Node, but also to
> >    the Home Agent of the Mobile Router in the mobile network.  This
> >    suffers the same amplification effect of nested Mobile Router
> >    mentioned in Section 2.2.
> > 
> > Well, if this is a VMN and if packet must be routed to the home
> > agent of the VMN, it means it operates MIP6. So, why would the
> > packet be sent to the VMN's HA ?
> 
> Sorry, I don't quite catch your question.  Is there a typo somewhere
> in your question?

What I mean is that if the VMN operates MIP6, the path will be optimized
to avoid the VMN's HA.  So, you end up with the same routing
inefficiency as for a LFN. 

> Perhaps, unless someone comes up with a side effect of RO that is

So, you can also turn this into a way (a benefit) or another (an issue).
Doing both is just not necessary IMHO.
 
> > Is this an issues for a VMN ? Isn't it always the case for a MIP6
> > node and couldn't it be considered as "normal" ?
> 
> Huh?  No, current specs in RFC 3775 does not require a MIPv6 in a
> Mobile Network to know any information about the MR.

I guess I missread before writing the comment.

Thierry

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 09 Mar 2005 04:49:43 +0800

Hello Thierry,

> inefficiency as for a LFN. 

Ah, that is if the VMN is using RO with whatever CN it is communicating
with.  If not, the packet would be routed to the HA of VMN.  I believe
in the next paragraph of the text we continue on to explain what happen
if the VMN actually does RO with CN.

> Doing both is just not necessary IMHO.

Noted. I am not saying we must have a "Benefits" section.  I included it
to be complete, and see if anyone can come up with additional benefits
of RO.  I am not so certain that any benefits can be turn into an
opposite problem, unless you call a lack of that benefit a problem.
However, since we are not able to come up with any, Section 3 may indeed
be redundant.

/rgds
/cwng

---

From: "T.J.Kniveton" <[email-masked]>
Date: Wed, 9 Mar 2005 12:32:44 -0800

> No, and neither in RFC 3753 which I just checked.

I recommend staying away from terms like dog-leg and pinball. They are 
not very descriptive, so a reader unfamiliar with the literature and ML 
discussions wouldn't know what you're talking about.

TJ