Subject: Vidyas Review of draft-irtf-mobopts-ro-enhancements-00 (was Re: [Mip6] Review Comments and Questions on draft-irtf-mobopts-ro-enhancements-00.txt)

From: Christian Vogt <[email-masked]>
Date: Thu, 09 Jun 2005 15:27:46 +0200

Hy Vidya,

based on your review, I revised the RO Enhancements document.  You can
check the new version at

http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-01-pre.txt

Thanks again for your comments,

- Christian

++++

> 1. The draft provides a good, comprehensive overview of the security
>  aspects of RO and the solution space in general. However, given that
>  there is already a draft on RO security, perhaps the security
> aspects should be integrated with that draft and this draft should
> attempt to cover the solution space alone?

The security aspects discussed in the document certainly cannot replace
the RO Security Background.  Nevertheless, Jari and I thought we should
put them in to give the reader just enough of background she or he needs
to understand the document.

Definitely, if the Research Group decides to remove the security section
from this RO Enhancements draft, or move it to the RO Security
Background, we'll do that.

Please don't mind that I leave the security section in the document
until we decide what to do.

> 2. Need for "fast" RO - The draft mentions in a few places (including
>  section 4) that one of the objectives for RO is latency
> optimization. I belong to the group that is yet to be convinced that
> there is a real need for "fast" RO. In my mind, there is a need for
> fast handoffs, but not necessarily fast RO. I don't think that RO is
> going to satisfy the latency requirements of real-time applications.
> Link layer mechanisms are defining methods to reduce the handoff
> latency to less than 100ms or so. Such enhancements are useful during
> inter-subnet handoffs only if the network layer latency can be
> reduced to adding very marginal latency on top of that. Do we really
> think RO is going to buy us that? Given that any design for RO cannot
> control the relative positions of the CN and the MN, it doesn't seem
> like any RO solution can claim that. The need for such applications
> really drives us towards FMIP-like approaches.

What you identify is an exemplar for the trade-off between good
performance and high investment costs. ;)

But there have also been comments (by James and Samita) to remove the
parts on FMIP and HMIP from the RO Enhancement draft.  The reason being
that both may be combined, but are not directly related to RO.

Still, you are making a good point.  I added this to the Conclusions.

> I still think RO can be useful - when long periods of traffic
> exchange happens between an MN and CN, it may be better to get away
> from triangular routing. I noticed that James brought up the point of
> almost ubiquitous wireline bandwidth perhaps eliminating the need for
> RO. While that is a very valid argument against the real need for RO,
> I think it will still be good to design the support for RO, before
> widespread deployment of CNs that don't support it.

Yes, I agree.

You may also want to avoid that all data goes through a single of of
failure, i.e., the home agent (unless you do HA relocation, of course).
  In fact, this contradicts the original Internet design guideline to
make communications robust to outages of some network entities.

> I am only questioning the need for latency reduction as a design 
> objective for an RO solution.

I think it's attractive, even for not-so-delay-sensitive applications,
to reduce global signaling delays from two RTT to one RTT.

> 3. One of the situations in which RO can be useful is when the RO 
> solution allows the MN and CN to continue communication during a
> period of HA unavailability (failure, for e.g.). The current RR
> solution does not achieve this, due to the necessity for short
> lifetimes and hence the need for home address tests via the HA every
> so often. It may be worthwhile adding this to the design goals for
> the solution.

That's an excellent comment.  This affects both data packets and
signaling packets.  (See my comment from above.)

I added a sub-section on this to section 4.

> 4. Section 3.3 (last paragraph) mentions the fact that the current RR
>  solution trades off protection against attacks on CN's processing 
> capacity for protection against CN's memory. Perhaps an RO solution
> can be flexible enough to allow the CN to determine what trade off
> makes sense in a particular case?

That's right.  Added this to section 3.3.

> 5. Section 6.2.1 talks about HMIP and FMIP-like proposals. I am not
> sure I understand how such proposals can replace RO. For e.g., the
> use of FMIP will remove stringent latency requirements on RO, but not
> provide a solution for RO itself, right?

You are right:  One should emphasize that there are two aspects of RO:
Routing data packets the direct way, and making end-to-end signaling
efficient.  This document talks about the latter.

I added this clarification to section 5.15.

Ok, best regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

Narayanan Vidya-CVN065 wrote:
> Here are some comments and questions I have from reviewing the draft.
> 
> 
> Thanks, Vidya
> 
> 1. The draft provides a good, comprehensive overview of the security 
> aspects of RO and the solution space in general. However, given that 
> there is already a draft on RO security, perhaps the security aspects
>  should be integrated with that draft and this draft should attempt
> to cover the solution space alone?
> 
> 2. Need for "fast" RO - The draft mentions in a few places (including
>  section 4) that one of the objectives for RO is latency
> optimization. I belong to the group that is yet to be convinced that
> there is a real need for "fast" RO. In my mind, there is a need for
> fast handoffs, but not necessarily fast RO. I don't think that RO is
> going to satisfy the latency requirements of real-time applications.
> Link layer mechanisms are defining methods to reduce the handoff
> latency to less than 100ms or so. Such enhancements are useful during
> inter-subnet handoffs only if the network layer latency can be
> reduced to adding very marginal latency on top of that. Do we really
> think RO is going to buy us that? Given that any design for RO cannot
> control the relative positions of the CN and the MN, it doesn't seem
> like any RO solution can claim that. The need for such applications
> really drives us towards FMIP-like approaches.
> 
> I still think RO can be useful - when long periods of traffic
> exchange happens between an MN and CN, it may be better to get away
> from triangular routing. I noticed that James brought up the point of
> almost ubiquitous wireline bandwidth perhaps eliminating the need for
> RO. While that is a very valid argument against the real need for RO,
> I think it will still be good to design the support for RO, before
> widespread deployment of CNs that don't support it.
> 
> I am only questioning the need for latency reduction as a design 
> objective for an RO solution.
> 
> 3. One of the situations in which RO can be useful is when the RO 
> solution allows the MN and CN to continue communication during a
> period of HA unavailability (failure, for e.g.). The current RR
> solution does not achieve this, due to the necessity for short
> lifetimes and hence the need for home address tests via the HA every
> so often. It may be worthwhile adding this to the design goals for
> the solution.
> 
> 4. Section 3.3 (last paragraph) mentions the fact that the current RR
>  solution trades off protection against attacks on CN's processing 
> capacity for protection against CN's memory. Perhaps an RO solution
> can be flexible enough to allow the CN to determine what trade off
> makes sense in a particular case?
> 
> 5. Section 6.2.1 talks about HMIP and FMIP-like proposals. I am not
> sure I understand how such proposals can replace RO. For e.g., the
> use of FMIP will remove stringent latency requirements on RO, but not
> provide a solution for RO itself, right?

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6