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

[Jari Arkko <[e-mail]>]

Hi Samita,

and thanks for the good questions! I'll try to answer
them, inline:

>Agree that one RR scheme may not fit all types of applications.
>Thus we can have base RR and another optional RR scheme...
>  
>
Ok.

>I have somewhat basic understanding on the two optional mechanisms you
>mentioned. Based on that, IMHO, EBU/CBA mechanism seems simple and
>practical and needs least amount of code change on top of
>current RR scheme in the base OS. We have seen some of the
>case studies on this method so far in mobopts - perhaps we need
>to study more on the timing of stay at one place; CBA offers 
>nice feature to delay the renewal of BU thus reducing traffic
>unnecessarily and so the signaling.
>
>Both scheme reduces handover delay compared to the base draft.
>  
>
Yes, although their primary intent is to reduce
different components of the delay and overhead. Namely, CBA
helps with being able to send traffic while care-of test
is still going on, and CGA helps removes most home
address tests. Both can impact latency, although CGA
impacts also number of messages. Finally, CGA impacts
signaling even when you are at the same location, whereas
CBA helps only if you have an actual movement.

>OMIP/CGA on the other hand may be useful for frequent movement
>between cells - but it needs MN to send pre-binding msgs. How
>much saving of signaling messages do we have here compared to the base RR ?
>Also it sends CGA key, Extended sequence number options etc.. So, these
>options carry extra bytes with regular BUs. 
>
>Has any study been done comparing EBU/CBA and OMIP/CGA  in terms
>of latency difference and handover advantage ?
>
>With the data available, I am not sure if we need both drafts to be
>standardized.  EBU/CBA seems to be a lot simpler from implementation
>perspective if we compare the benefits of the two drafts.
>However, CGA optionally can provide protection on the addresses.
>
>So how about having EBU/CBA with optional CGA key exchange for
>extra security ? If we can save Home address test exchange for
>the handover - we can save time there.
>
>  
>
The last paragraph more or less what I had in mind (although
both parts have to be optional in some sense). Basically,
CGA and key exchange makes it possible to eliminate
most home address tests. This is in fact a bit more necessary
in EBU/CBA than in base RFC 3775, because in order
to reduce latency, you'd either want to have a home keygen
token handy just in case you move soon (more signaling)
or do it faster when you have moved. CGA + Key
eliminate the need for this. Some could argue that the
home test roundtrip is typically longer than care-of
test roundtrip.

Re: additional pre-binding messages. All of the current
proposals for RR enhancements have some added signaling
somewhere. RFC 3775 RR is rather stateless in the sense
that when you move, you always do everything. CGA + Key
approach basically involves a one-time setup cost, after
which subsequent movements have a cost that is 50%
of the RFC 3775 cost. All long data items are sent only in
the initial setup messages. Whether all this makes sense depends
primarily on the number of Binding Updates -- however its
good to remember that in RFC 3775 you have to send Binding
Updates every couple of minutes. This can be eliminated
with a longer home test lifetime, which CGA can provide.
This can be important for battery lifetime and aggregated
bandwidth in cellular networks.

Some theoretical calculations about the impacts of
different methods can be found in Section 9 of
draft-haddad-mip6-cga-omipv6-03.txt. For instance,
a stationary mobile node (sounds funny but its really
a quite common case) gets upto a 200-fold decrease
in amount of signaling packets.

So, we could compare the two approaches but at the
end of the day, they optimize different parts, and the sum
of those parts is what the user sees. It consists of both
latency (care of test, home test, other things) and signaling
overhead.

--Jari


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