Subject: [nemo] review of draft-ietf-nemo-ro-problem-statement-00.txt

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Aug 2005 14:45:06 +0300

Hi all,

I read this draft and found it generally OK.

Some comments:

I was convinced that route optimization is useful even
prior to reading this document, and would probably have
been convinced of it even by a shorter document.
I understand that some solutions in this space are
being considered by the WG, and I look forward
to seeing how they solve issues that come up.

One aspect of the justification for work in this
space was not covered in the draft, however.
We do understand well the technical implications,
but it would be interesting to hear about vendors
and service providers wishing to deploy nemo
technology, and their specific expectations. There
are a number of reasons why route optimization can
be useful, but some of those reasons are very
different from each other. For instance, if we
need a solution for loop avoidance that may be
very different from issues relating to pure
optimization of RTTs and header sizes. Different
types of networks have also different requirements
regarding letting visiting nodes route traffic through
home networks. And disadvantages of extreme
nesting may or may not be a real issue, depending
on the type of networks being planned.

Before we start new work it would probably make
sense to understand what the use cases and the
demand is. (Of course, you probably have discussed
all this already -- I have not followed the list closely.)

>   NEMO Basic Support presents a number of additional issues, making the
>   problem more complex, so it was decided to address Route Optimization
>   separately.  In that case, the expected benefits are more dramatic,
>   and a Route Optimization mechanism could enable connectivity that
>   would be broken otherwise.  In that sense, Route Optimization is even
>   more important to NEMO Basic Support than it is to Mobile IPv6.
>  
>
This worries me a bit. Route optimization in Mobile IPv6 was
never designed as a mechanism that guarantees optimal
routing: correspondent nodes can refuse to honor requests
based on resource constraints, there may situations where
some traffic needs to be routed through tunnels anyway, etc.
Of course, what ever solutions we come by in this space
need to deal with these issues. I'm just making an observation
that this may imply a solution that is quite different, or
even completely distinct, from the current Mobile IPv6
mechanisms.

> When Mobile
> Routers have no prior knowledge of their peers (no Security
> association, AAA, PKI etc...) it can still be mutually beneficial to
> apply a form of reciprocal altruism based on anonymity and
> innocuousness.  In particular, it is possible to adopt a tit for tat
> (T4T) strategy and forward traffic unless the other party proves to
> be uncooperative when it is solicited.
>
This is interesting, but might also be its own problem
area all by itself.

>   Then again, a Route Optimization mechanism that bypasses the nested
>   tunnel might enable the parent traffic to reach the Internet and let
>   it bind.  At that point, the child Mobile Router would be able to
>   reach its parent and bind in turn.  Additional nested Route
>   Optimization solutions might also enable the child to locate its Home
>   Agent in the nested structure and bind regardless of whether the
>   reach to the Internet is available at all.
>  
>
It isn't clear to me that this can be done. Most route
optimization schemes appear to need some roundtrips
through the "home", so lack of internet connectivity
would probably be a problem, at least if its prolonged.
There are also schemes that do not need "home"
participation, but it remains to be seen if we could
make them compatible with Mobile IPv6-based schemes.

Anyway, I'm looking forward to the solutions proposals...

>5.  Security Considerations
>
>   This is an informational document that describes some limitations
>   with NEMO Basic Support and does not introduce any additional
>   security concerns.  Please see RFC3963 [1] for security
>   considerations pertaining to the NEMO Basic Support protocol.
>
Avoidance of home network policy controls or
the t4t mode would probably imply some new
security issues to think about. Might be worthwhile
to mention them here.

Editorial comments:

>      Agent on the Internet, the increase in delay is tremendous.
>
s/tremendous/larger/ (I prefer to use milder words,
at least for me it makes the case better than strong
argumentation.)

--Jari

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 24 Aug 2005 12:00:01 +0800

Hello Jari,

Thanks for your comments.  See response in-line.

> on the type of networks being planned.

Yes, unfortunately that is one of the common problems.  Operators and
service providers tends not to be very vocal in mailing lists.  I would
like to take this opportunity to urge them to provide their inputs
regarding route optimization.

Also, in response to some of the observations you made below, I would
like to point out that there is going to be a separate WG draft (that
should be published by early September) that analyzes the NEMO RO
solution space.  It might address some of your concerns.

> security issues to think about. Might be worthwhile

Right. Will do.

> at least for me it makes the case better than strong

Fine ;).

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Aug 2005 17:00:52 +0200

Jari Arkko wrote:
> I was convinced that route optimization is useful even prior to 
> reading this document, and would probably have been convinced of it 
> even by a shorter document. I understand that some solutions in this
>  space are being considered by the WG, and I look forward to seeing 
> how they solve issues that come up.
> 
> One aspect of the justification for work in this space was not 
> covered in the draft, however. We do understand well the technical 
> implications, but it would be interesting to hear about vendors and 
> service providers wishing to deploy nemo technology, and their 
> specific expectations.

I agree completely that it would be interesting to hear about vendors
and service providers wishing to deploy nemo tech and their
expectations, before looking at developping RO solutions for nemo.  That
will probably be precluded by a need for more implementation and test
work, of Basic non-RO support, by independent actors.  This is why it is
significant to have implementation&deployment aspects of Basic Support
in the Charter about to be re-written.

> There are a number of reasons why route optimization can be useful, 
> but some of those reasons are very different from each other. For 
> instance, if we need a solution for loop avoidance that may be very 
> different from issues relating to pure optimization of RTTs and 
> header sizes. Different types of networks have also different 
> requirements regarding letting visiting nodes route traffic through 
> home networks. And disadvantages of extreme nesting may or may not be
>  a real issue, depending on the type of networks being planned.

I agree.

> Before we start new work it would probably make sense to understand 
> what the use cases and the demand is.

I agree.  I feel a little bit that need for deploying NEMO RO may arrive
much later than the desire to specify it, which may lead to
over-specifying something that nobody needs.  Just a gut feeling.

> [...]

>>  tunnel might enable the parent traffic to reach the Internet and 
>> let it bind.  At that point, the child Mobile Router would be able
>>  to reach its parent and bind in turn.  Additional nested Route 
>> Optimization solutions might also enable the child to locate its 
>> Home Agent in the nested structure and bind regardless of whether 
>> the reach to the Internet is available at all.
>> 
>> 
> It isn't clear to me that this can be done. Most route optimization 
> schemes appear to need some roundtrips through the "home", so lack of
>  internet connectivity would probably be a problem, at least if its 
> prolonged. There are also schemes that do not need "home" 
> participation, but it remains to be seen if we could make them 
> compatible with Mobile IPv6-based schemes.

I agree that common RO schemes need to go through home and anything
different may distance itself too much from what the MIP6 RO scheme is.

I just wanted to mention that it is important to see the need-for-RO
topics listed by the draft (sub-sections 2.x) as separated in two: those
that relate to performance and those that related to work-or-dont-work.

For example, topics 2.1-2.4 are obviously performance related while 2.6
and 2.7 can be seen as issues with the NEMO Base Support protocol
itself.  These latter suggest that in certain mobility scenarios the
protocol can't work.  And that if an RO mechanism existed then moving
networks as described could work.

Which brings me back to the vendor/deployment needs.  I could say that
if vendor/deployment needs are only about one moving network (and not
about nestedness) then the protocol will work fine without RO, albeit
with applications noticing performance decrease because of long paths.
But it would work.

Alex