Re: RR enhancements (Was: Re: [Mipshop] MIPSHOP discussion on new items and milestones)

[Wassim Haddad <[e-mail]>]

On Sun, 20 Mar 2005, Christian Vogt wrote:

> Hi everybody.
>
> Sorry for jumping into this thread late.
>
> > I have high reliance that the basic schemes are solid, even if
> > there's certainly work left for a number of I-D revision cycles. CGA
> > has been around longer than base RR, and if you take all the advanced
> > asymmetric flow stuff away from CBA, you get a very simple scheme.
>
> Let me just clarify this for those folks who are not so familiar with CBA.

> The CBA proposal currently under discussion in Mobopts introduces two
> "modes".  In the "simple mode" (let's call it so for now), the CN gives
> credit to a MN for packets received from the MN.  The CN reduces the
> credit for packets that it sends to it at an unverified CoA (for which a
> *concurrent* CoA test is still in progress) of the MN.  This is the
> easiest way to rule out any amplified flooding attacks that malicious
> MN's may otherwise use their unverified CoA's for.

=> Can you please explain more on this? For example what happens after I
get enough high credits from the CN? Does this mean that I won't have to
do the CoTI/CoT messages in the future? Or I can simply increase the delay
to do it?

OTOS, is there any relation between the number of credits provided for
each packet and the _number_ of previous handover also?

> The simple mode is easy to implement; we did this for Kame-Shisa Mobile
> IPv6.  Also, the simple mode is transparent to the MN; only the CN needs
> to implement it.

> In the "advanced mode", the CN gives a MN credit for packets that the MN
> has received from it (i.e., for packets going into the opposite
> direction than in simple mode).  The advantage here is that the same
> communication direction is used for increasing and decreasing the
> credit.  Applications with asymmetric traffic streams like TCP downloads
> and streaming may work better in the advanced mode.  More symmetric
> applications like VoIP and video conferencing are fine with both the
> simple and advanced mode.
>
> Yet, for the CN to know how may packets the MN actually receives, the
> advanced mode needs some sort of packet-loss feedback.  We thus
> introduced an optional in-band-signaling mechanism, CoA spot checks.
> CoA spot checks require support from the MN, however.
>
> Due to the additional complexity and the loss of transparency, Jari's
> suggestion (and Gabriel's earlier suggestion) is to standardize the
> simple CBA mode, and leave the advanced CBA mode to Mobopts.  I do
> support this approach, but I should add that I am a co-author of CBA.

=> Good to have a confirmation but your name is in clear on the draft!

> Standardizing simple CBA can well be done in a way complementary to, but
> independent of, CGA-OMIPv6.  BTW, the HIP community will integrate
> simple CBA to HIP mobility, too, as decided at IETF 62.

=> Good to know. But I don't see the link!


Wassim H.


> Jari Arkko wrote:
> > Vijay Devarapalli wrote:
> >
> >>> Finally, I wonder what you would consider as a MOBOPTS
> >>> recommendation? We already have WG documents that do precisely
> >>> what you say above, i.e., state that there are some methods that
> >>> are quite stable. Ok, I admit that I'm an author of such a
> >>> document but we have done quite a lot of analysis in
> >>> draft-irtf-mobopts-ro-enhancements and I think we can back our
> >>> statements up with a good rationale.
> >>
> >> thats good. I havent been following this work. if MOBOPTS thinks
> >> they are ready, they be should be brought right away to the MIP6
> >> WG. but, I would like to see one RR enhancement standardized. not
> >> multiple ones. Jari, you tell me which one is ready. I trust you
> >> enough to just go with your recommendation. :)
> >
> > Thanks, but I may have to disappoint you! See, the problem is that
> > people have different objectives. For instance, having a scheme that
> > is blazingly fast may make voice over IP people happy. But people who
> > wanted to save their battery life may not be happy with the resulting
> > signaling. Or someone wants to setup a shared key between his laptop
> > and home server may like his solution, but that might not satisfy
> > others who want to use this stuff with a random web server in the
> > Internet.
> >
> > Anyway, here's one suggestion that would perhaps make you happier.
> > The EBU/CBA direction has been studied mainly in an attempt to make
> > handoffs faster and to reduce latency. The technical solution boils
> > down to a better way of performing the care-of address test. The
> > OMIP/CGA direction has been studied mainly in an attempt to reduce
> > signaling and to make handoffs faster. The technical solution boils
> > down to a better way of performing the home address test.
> >
> > This suggests potential way forward, as we realize that the two
> > different approaches are complementary. If you use them together, we
> > get a new "super RR" that keeps the original zero-config nature of
> > zero-config RR but has less latency and less signaling.
> >
> > I have high reliance that the basic schemes are solid, even if
> > there's certainly work left for a number of I-D revision cycles. CGA
> > has been around longer than base RR, and if you take all the advanced
> > asymmetric flow stuff away from CBA, you get a very simple scheme.
> >
> > --Jari
> >
> > *) Note that I don't think the two documents should be combined since
> >  the solutions are orthogonal. And in some cases you may want to do
> > just one of them, e.g., if you care so much about battery power that
> > you want to sacrifice some latency to avoid sending a couple of extra
> > packets. But if both improvements were adopted, we would have a
> > deployable and efficient new scheme.
>
> --
> Christian Vogt, Institute of Telematics, University of Karlsruhe
> www.tm.uka.de/~chvogt/pubkey/
>
>

_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop