Subject: Re: [mobile-ip] WG feedback on bicasting

From: James Kempf <[email-masked]>
Date: Tue, 24 Jul 2001 10:09:22 -0700 (PDT)

Wolfgang,

Most of these problems go away if bicasting is done between oFA/oAR
and nFA/nAR. 

The exchange of L3 handover messages across the wired backbone
(HI/HACK) is a coarse approximation of when the link changes. 
The oAR continues to send packets down the old L2 until the
L2 disappears. Presumably it can detect this somehow. It starts bicasting to nAR 
when it sends/receives a HACK. 

This can be fine tuned considerably if appropriate sequencing
information is available from L2 (see draft-manyfolks-mobilereq-l2-00.txt
for the kinds of sequencing information that can help).

		jak

>Date: Tue, 24 Jul 2001 17:43:40 +0200
>From: Wolfgang Schoenfeld <[email-masked]>
>To: [email-masked]
>Subject: Re: [mobile-ip] WG feedback on bicasting
>
>Hello Karim,
>
>may I just restate my considerations
>which had - I admid - a few flaws?
>
>Assume again that a stream of packets 
>is running from CN to MN via oFA (or oAR or ...).
>When MN moves, some redirection of the stream may be necessary
>(which is done by registration at the HA).
>Which events can trigger that?
>
>The emergence of a new link between MN and some nFA is a good candidate
>since the stream can use it (as long as it is stable).
>And this is what MIP does.
>However, to propagate the event to HA takes some time
>during which packets keep on running to oFA.
>And after redirection is done,
>packets take some time to reach MN.
>Hence, the round-trip time from MN to HA 
>determines handoff latency time.
>
>Obviously, it can be reduced
>by bringing HA functionality closer to MN -
>which is the purpose of hierarchies.
>What else can be done?
>Nothing if we consider layer 3 alone
>since this would mean to by-pass registration message or data packets.
>In particular, bicast/multicast will not help.
>
>Another (the only?) way is guessing the emergence of a new link,
>i.e. taking outer "oracles" like layer 2 events, statistics etc. into account.
>In this case, bicasting can indeed make sense
>if the guess does not give a unique answer:
>Just multicast to all nodes which the guess predicts.
>(Broadcast would result from the most vague guess.)
>This increases the probability that all packets reach MN.
>
>Note however that multicast is concerned only with vagueness of guesses -
>if they are precise, multicasting does have not have any effect.
>Hence, fast handover without bicasting 
>(your original question) does make sense.
>
>I'm not sure whether the above is now "gap-free". Hence, please comment.
>
>Wolfgang
>
>PS:
>Concerning James' "Handover Smoothing - What to Do?"
>which I appreciate very much -
>wouldn't it be reasonable to also have, for each of the proposals,
>some analysis of
>
>- Which cases are handled by the proposed architecture / functionality?
>- In these cases, what is the improvement achieved?
>- How often do these cases happen?
>
>
>"Karim El-Malki (ERA)" schrieb:
>> 
>> Hello Wolfgang
>> 
>> > I'm not able to comment on mobileip WG issues,
>> > but I believe that the role of bicasting for handover
>> > is not yet fully understood, both in MIPv4 and MIPv6.
>> > Considerations like the following for MIPv4
>> > might help to decide.
>> 
>> The aim of the draft is exactly to address the role
>> of bicasting in fast handovers (for MIPv6) and address
>> issues involved.
>> 
>> >
>> > Obviously, bicasting makes sense only if MN is able
>> > to maintain more than one link simultaneously,
>> > say to oFA and nFA.
>> 
>> That's not what the draft says and actually quite the
>> opposite.
>> 
>> > Now assume that this is the case
>> > and consider handover without bicasting.
>> > Handover involves, among others, these events:
>> >
>> > (A) MN detects a link to nFA and issues a BU message to HA.
>> > (B) HA receives BU and updates binding of MN.
>> > (C) MN looses the link to oFA.
>> >
>> > How is a stream of packets from some CN to MN affected by handover?
>> > (A) does not affect the stream, but (B) does:
>> > Before (B), packets travel to oFA,
>> > and after (B), they travel to nFA
>> > (assume that HA buffers during (B)).
>> > Packets passing HA after (B) will reach MN,
>> > but what about those
>> > which pass HA before (B) and after (A)?
>> > Let us call them "critical" packets.
>> 
>> The bicasting draft applies to fast handover v6 but your
>> example is different. You're also considering MIPv4 but this
>> draft is on MIPv6...
>> So I guess your comments are not on the draft itself but on
>> generic bicasting?
>> If you follow the fast handover v6 concepts then A & B would
>> occur some time in advance of when C occurs. We assume this
>> anticipation is enough such that the "critical" packets reach
>> the MN at its old link. That's also a good reason to use
>> a close-by or local HA like the MAP from HMIPv6. In fast
>> handover v6 the anticipated F-BU is sent to the oAR. So this
>> should not involve loss of "critical" packets.
>> 
>> > If (C) happens only after all critical packets
>> > have passed the link from oFA to MN,
>> > then there is no packet loss at all.
>> 
>> That's why the handoff is anticipated.
>> 
>> > Now, what could bicasting improve?
>> > Non-critical packets need not be bicasted -
>> > they will reach MN anyhow.
>> 
>> That's not necessarily true. The l2 handoff may
>> occur at any time relative to the MN's BU.
>> What if the MN hands-off (L2) to the new AR a certain
>> time after having sent the Fast-BU? Since the MN has
>> not moved yet the packets sent to nAR during this
>> time interval get lost. Bicasting instead gives us a
>> way to decouple l2 and l3 handoffs: the MN can communicate
>> no matter when the L2 handoff occurs. This is
>> discussed in the draft.
>> 
>> > To summarize,
>> > simultaneous use of two links to MN - if they exist -
>> > is somehow "built-in" and can happen
>> > even if simultaneous binding is switched off.
>> 
>> In fact bicasting is probably more useful on MNs with a
>> single link.
>> 
>> > Switching it on will have no effect on packet loss!!!
>> > Bicasting does not make sense.
>> >
>> > It does make sense only if HA is able to predict (A).
>> > But move prediction is, as far as I understand,
>> > not an issue for MIPv4 or for MIPv6.
>> 
>> Is it more clear now?
>> You were assuming things that are neither according to
>> fast handover v6 draft nor the bicasting draft which is
>> why you were coming to these conclusions.
>> 
>> Regards
>> /Karim
>
>-- 
>Prof. Dr. Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 
Darmstadt
>Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455

---

From: Wolfgang Schoenfeld <[email-masked]>
Date: Thu, 26 Jul 2001 17:44:13 +0200

> Most of these problems go away if bicasting is done between oFA/oAR

This is what I meant with 
"to by-pass registration message or data packets"
travelling on the "standard" path oFA - HA - nFA
via some direct link (or tunnel) oFA - nFA.

> for the kinds of sequencing information that can help).

Have to go into that...

Wolfgang
-- 
Prof. Dr. Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt
Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455