Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

From: Phil Roberts <[email-masked]>
Date: Sun, 29 Jul 2001 21:06:29 -0400

So this is the message to which I responded, "I don't buy it."  You
requested
more detail.

Here is the general observation.  You are proposing bicasting as a solution
that
solves only a part of the handover smoothing problem, that is the potential
loss
of packets in flight between an HA or hierarchical MIP agent and an FA or
AR.  That's
fine as far as it goes and it seems it should be made clear that this is
*all* it
does.  It does not help in the general case of interruption of flow between
oFA/MN and
nFA/MN.  I believe you agree to this below when you say the examples I put
forth were
L2 specific.

More on those below.

> -----Original Message-----
> From: Karim El-Malki (ERA) [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 10:44 AM
> To: [email-masked]'
> Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
> 
> 
> > They are both receiving packets without any knowledge of what 
> > the other
> > has received, or has forwarded to the MN.  Might you not have 
> > a situation
> > like this?
> 
> I agree that there should not be the need for nFA to know what
> oFA has transmitted. What I'm saying is that if you bicast and
> (if needed) have an appropriate (jitter) buffer size at nFA then
> it should be possible to avoid duplicates. More below.
> 
> > 
> > At a single point in time the MN is no longer reachable from 
> > the oFA and is
> > not yet reachable on the nFA.  At that point in time a packet 
> > arrives at
> > both
> > oFA and nFA and they discard the packet.  The MN attaches to 
> > the nFA but the
> > packet is gone.  (That's in case A you describe).
> 
> I would think that this is an effect of L2 (i.e. L2 handoff time)
> and we are mostly aiming to minimise/eliminate effects due to L3.

Good.  We're agreeing so far.

> Also what I was pointing to is that a buffer is probably needed
> if the handoff time from oFA to nFA is not negligible (your next
> case and this case). That's why packet dropping is a MAY. So this
> case wouldn't happen, unless of course it's not TCP and you don't
> care about dropping some packets. In fact low latency handoffs are
> probably most useful for real-time services (e.g. Voice on UDP)
> in which case, if there's an period of L2 disconnection during
> handoff, the packets should be dropped.

So here we need some kind of information that describes FA or AR
behavior wrt duration of the handoff time and whether or not it's
TCP traffic or something that is realtime traffic.

> 
> > 
> > Or like this?
> > 
> > At a single point in time a packet arrives at the oFA and is 
> > sent to the MN
> > and
> > at the same time arrives at the nFA and gets buffered.  The 
> > MN disconnects
> > and then reconnects at the nFA and gets a second copy of the packet.
> > (That's
> > in case B you describe).
> 
> The buffer size should be set such that you don't get duplicates.
> By the time MN connects to nFA, the second copy of the packet
> should be dropped out of the FIFO queue/buffer and the next one
> should be ready for sending to MN. Of course this calculation
> depends on the l2 handoff characteristics and possibly the wired
> connectivity between the bicasting point and oFA/nFA.

I agree with this, but I don't know how to do it.  Now we need to add
to the decision matrix characteristics about the wired connectivity.

But still, it doesn't take into account latency within the network.
Whereas it seems that a receiving station might be able to make some
intelligent decisions about when it is important to drop a packet (because
it arrived way too late), but now do you want the network in between to get
involved in the measurement and timing of these decisions? 
> 
> > 
> > Or like this?
> > The same packet arrives at oFA and is transmitted to the MN 
> > which then moves
> > to the
> > nFA and gets the same packet which was delayed on its way 
> to the nFA.
> 
> That would again need to be handled by a jitter-smoothing 
> buffer at nFA.

OK, but how?  A packet arrives at the nFA.  How does the nFA have any idea
whether or not it needs to be buffered and then for how long, or dropped?
In
this case it should be dropped, in the previous case it should be dropped,
and in the first case it should be sent.  But the only way I know that is by
knowing what the MN has already received.

> 
> > 
> > Or like this?
> > The MN disconnects from the oFA the packet arrives and is 
> > dropped, then the
> > MN comes
> > back to the oFA because of radio conditions and the packet 
> > has been lost.
> 
> We could devise some temporary oFA buffer for this, but the L2
> handoff failure is pretty serious so I think that it is
> too much to expect smooth handoffs in this case. If we can
> maintain L3 connectivity then I think that should be good enough.
> 
> > 
> > It seems like there is some coordination needed between the 
> > oFA and the nFA
> > to
> > overcome these problems, perhaps a temporary tunnel?  But 
> in that case
> > bicasting from
> > an HA or a hierarchical FA wouldn't be adding much to it, 
> > would it.
> 
> Well, I think that having a local central HA would help.
> Say that oFA and nFA are at an equal distance from the GFA
> which is the aggregation router between the two. That could
> alleviate jitter on the fixed network, as has been already
> mentioned by James. Also, if oFA and nFA happen to be connected
> to each other through the GFA router, then bicasting at the
> GFA would be more efficient.

But wait a second.  What do you mean by equal distance?  Number
of hops, geographical distance?  It has to be transmission time.
Is this another item we need to add to our decision matrix?

> 
> >At any
> > rate
> > one would think that issues like this need some exploration 
> > and explanation
> > somewhere.
> 
> OK. Up to now there has been a lot of emphasis on TCP. Although I
> agree that it would be useful to give more detail of how bicasting
> + buffering works with TCP, we are also not considering the fact that
> a major driver for having faster handoffs at L3 was to support
> real-time services (over UDP). I would think that the issues above are
> not applicable to this case? If this is so then we should not apply
> these issues to bicasting/buffering in general and make that 
> clear too.
> 
> Rgds
> /Karim
>

So I guess in summary, "I don't buy it," means I'm not convinced by
your answers.  I've given some of my reasons why.

Speaking as a member of the working group now:

So what's my position on this?  It seems that there are fairly obvious
cases in which bicasting introduces packet duplicates with potentially
unknown
effects in the network.  It doesn't seem the network agents will have the
information needed to prevent this from happening.

What I would recommend instead of including bicasting in the fast handoff
drafts for v4 and v6 is a placeholder that describes precisely what the
problem
is (of lost packets in flight) and that a solution needs to be provided.
The WG
debates the possible solutions and puts those in a separate draft.

Speaking as a working group chair now:

I'm doing a little work to find out whether a solution that introduces
duplicate
packets will be shot down by the IESG right off the bat.  It seems wise to
separate the fast from the smooth part, advance the fast, and produce a
solution
for the smooth later.

I will of course dutifully abide by the consensus of the working group.

Hope this helps,
Phil

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 30 Jul 2001 07:00:23 -0700

> information needed to prevent this from happening.

Just for clarification, duplicate packets already occur in the network.

So, why is the possibility of creating duplicates at the edges, during a 
handoff - which is infrequent - now become a real problem, when they 
already occur in the network without handoffs?

PatC