Subject: [Mobopts] RE: Vidyas Review of draft-irtf-mobopts-ro-enhancements-00 (was R e: [Mip6] Review Comments and Questions on draft-irtf-mobopts-ro-enhancem ents-00.txt)

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Mon, 13 Jun 2005 09:50:31 -0500

Hi Christian,
Thanks for incorporating my comments. No problem about leaving the security details in the document for now. It does give the reader a good background - perhaps it can be shortened in a later version if required. 

Regards,
Vidya

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Thursday, June 09, 2005 8:28 AM
> To: Narayanan Vidya-CVN065
> Cc: [email-masked]; [email-masked]
> 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)
> 
> 
> 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-0
> 1-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?
> 
> 

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