Re: [Mipshop] Review of Transient Binding Spec

[Marco Liebsch <marco.liebsch at nw.neclab.eu>]

Hi Rajeev,

Koodli, Rajeev schrieb:
>  
>   
>
>   
> > Why would the following text reduce the value of the transient binding cache
> > extension?
> >
> >    The problem that the transient binding cache mechanism is trying to
> >    address can also be achieved through implementation-specific mechanisms
> >    on the LMA, such a configuration on the LMA to accept uplink packets
> >    both from the pMAG and the nMAG during a handover and through buffering
> >    at the nMAG when the downlink packets starting arriving at the nMAG and
> >    the L2 link between the MN and nMAG is not setup yet. However, dynamic
> >    solutions by means of the proposed extension in this document is needed
> >    to optimize the performance for a variety of handover situations and
> >    different radio characteristics. See Appendix B for a more detailed
> >    discussion on this.
> >  
> >     
> well, if you propose to write that by implementation "The problem ....
> can be achieved...",
> maybe you're right that this makes the problem worse.
>
> Rajeev:> Well,  it is meant to say the "..solution to the problem can be achieved..", right?
>   
I read this differently.

>  
>
>   
> > On 8/18/09 1:13 AM, "Marco Liebsch" wrote:
> >
> >  
> >     
> > > The document will be RFC Experimental first. Folks can implement and can get
> > > convinced about the benefit:complexity-ratio. I do not see any value in
> > > adding a misleading note to the
> > > spec that folks should not implement this as you may solve it by static
> > > implementation.
> > >    
> > >       
> > On the contrary, I don't see the above text misleading a reader. It only
> > says that there are other options (which is true), but the protocol
> > extension as specified in the draft make sense. For a detailed discussion,
> > see the appendix.
> >  
> >     
> The text is misleading and pretends that the problem can be solved by
> static configuration. Yes, there are other options, which address some of
> the problems we talk about, at the costs of configuration complexity and
> having a "one solution for all handover situations" approach, which results
> in possibly even worse performance. This does not solve the problem. And
> this is what the proposed text says. No protocol specification starts
> this way.
>  
> Rajeev:> implementations at LMA and nMAG can address the problems. It is fair to argue that there are benefits by having a protocol such as this. However, it is necessary to state what is feasible without the protocol.
>   
This is exactly what the proposed text below says: "Implementation 
specific solutions can address the problems".
But I revised again based on your comment below (please see below)

>  
>
> Any fast handover mechanism for IP mobility could solve the problem
> with less signaling if you , for example, administratively set up a list of
> globally adjacent ARs and N-cast packets during a handover phase...
>
> Rajeev:> I don't recall anyone bringing this up.. We could have discussed it.
>   
Possibly it has not been brought up because nobody expects such text in 
a protocol solution.
But it's the same here: It addresses the problem, but does not solve all 
problems as the
protocol does.


>  
>  
> No protocol would write this, as it deviates from the original idea.
> The current version of the draft covers an analysis of the
> drawbacks with solving the handover problems with static configuration.
> This has been added to address a comment we received. We should proceed
> now. If really more text needs to be added to the Introduction, we propose
> the following for the update:
>
> "Some implementation specific solutions, such as static configuration
> and introducing some delays, may help to reduce some issues addressed in
> this draft, see Appendix B. However, dynamic solutions by means of the
> proposed protocol operation is needed to optimize the performance for a
> variety of handover situations and different radio characteristics."
>
> Rajeev:> The text above talks about advanatages/disadvantages. I would go with Vijay's proposed text. 
> Besides, it is not clear to say it is "..needed" for an Exp protocol. 
>   
Ok, will revise again. But since you point to the status Expeimental: 
Even more weird to add such
confusing text in the core part of a specification. As you said, it's 
experimental. Folks
can implement and evaluate it. If there are alternative approaches, such 
as playing with
implementation specifics and static configuration, well, folks can do 
and compare.
Alternative solutions and their performance, this is usually what 
conference papers
write about..

Ok, here is the revised proposal:

"Some implementation specific solutions, such as static configuration
and introducing some delays, may help to reduce some issues addressed in
this draft, see Appendix B. However, a dynamic solution by means of the
proposed protocol operation helps to optimize the performance for a
variety of handover situations and different radio characteristics."

marco






>  
> -Rajeev
>  
>
> marco
>
>
>
>   
> > Vijay
> >
> >  
> >     
>
>
> _______________________________________________
> Mipshop mailing list
> Mipshop at ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop
>