Subject: RE: [mobile-ip] Analysis of Latency Propagation with Buffering

From: Phillip Neumiller <[email-masked]>
Date: Wed, 1 Aug 2001 16:06:13 -0400

Hi Charlie,

A single pizza is not really a good example.  Its perhaps
better to think of yourself as SERVING pizzas to visiting
dignitaries and you have to keep the pizzas coming to ensure
that they are always happy (i.e. the pizzas are warm NOT
stale).  In this case if the dignitaries can be in two
possible places during certain periods of time (handoffs) 
it is VERY wise to send pizzas to both locations.  QED :-)

-pdn

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2001 3:42 PM
> To: Phillip Neumiller
> Cc: [email-masked]
> Subject: Re: [mobile-ip] Analysis of Latency Propagation with 
> Buffering
> 
> 
> Hello Phil,
> 
> If I order a pizza, and somebody brings me two, and
> charges me twice, that's bad.
> 
> If I get two for one for free, that's better, but from
> the standpoint of the restaurateur it would be nice
> if the government didn't tell him he HAD to serve me
> two for one.  Furthermore, if I'm tired of eating and
> I still have to swallow the extra food, I might complain
> even about the freebie.
> 
> If, on the other hand, I can buy just the pizza I want,
> and if I have to leave before I finish the meal but
> later I can ask for the slices that are still hot,
> that sounds about right to me.
> 
> Regards,
> Charlie P.
> 
> 
> 
> Phillip Neumiller wrote:
> > 
> > And it sure seems more logical to bicast since if you need it you
> > DONT have to ask for it and WAIT around the RTT!
> > 
> > -pdn
> > 
> > > -----Original Message-----
> > > From: Pat Calhoun [mailto:[email-masked]]
> > > Sent: Wednesday, August 01, 2001 1:28 PM
> > > To: [email-masked]
> > > Subject: Re: [mobile-ip] Analysis of Latency Propagation with
> > > Buffering
> > >
> > >
> > > On Wed, Aug 01, 2001 at 10:32:30AM -0700, Charles E. 
> Perkins wrote:
> > > > If a packet is received by the mobile node,
> > > > then presumably it would prefer not to receive the 
> buffered copy of
> > > > that packet at any time in the future.
> > >
> > > sure, otherwise that would sure look like bicasting :)
> > >
> > > PatC
> > >
>

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 2 Aug 2001 04:44:02 -0400

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 10:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mobile-ip] Analysis of Latency Propagation with Buffering

On Wed, Aug 01, 2001 at 02:17:45PM -0700, James Kempf wrote:
> Hi Charlie,
> 
> >
> >>> I wanted to clarify that it isn't buffering itself that adds delay.
> >>> A packet could be buffered AND transmitted to the mobile node at the
> >>> same time, which then would show that buffering does not have to
> >>> introduce any delay.  If a packet is received by the mobile node,
> >>> then presumably it would prefer not to receive the buffered copy of
> >> Well, I guess I agree, but what is the point of buffering if you
> >> are going to transmit it or of transmitting it if you are going
> >> to buffer it? The two options seem mutually exclusive to me.
> >> Am I missing something?
> >
> >The point of buffering and simultaneously transmitting is that
> >sometimes the mobile node might not be there to receive the transmitted
> >packet -- say because it moved to a new access router.  Then it would
> >request the previous access router to send the buffered packets that
> >it had not already received.
> >
> 
> OK, now I understand. I suggested something like this, but with
> the new AR doing the buffering, in Appendix B of the BETH draft.

in which case the mobile doesn't have to request the packets, since
opening the L2 would cause buffered packets to be released to the 
mobile node.

GT> I guess that works when the oldAR knows which packets were received by
the MN before the link went down...any remaining packets can now be
forwarded to the newAR and by the time the MN connects to it the packets
will be ready for delivery ...without requests or duplications...sounds good
to me too.

George

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 3 Aug 2001 00:11:17 +0200

Pat Calhoun wrote:
> 
> On Wed, Aug 01, 2001 at 12:42:14PM -0700, Charles E. Perkins wrote:
> > Hello Phil,
> >
> But chances are you'll end up with the remaining slices, which
> are now cold, and a new pizza that is warm as well.
> 
> So, if a packet stays around in a buffer long enough (and we're not
> talking that long), the peer will most likely retransmit, and you'll
> end up with dups anyways.

This is a matter for managing the probabilities for such occurrences,
and when it gets to that point the analogy cannot help any more.
But simulation and prototype indicate that the necessary data (slices
of pizza) can be consumed in enough time to help with voice.  And it
can be done in a way to avoid dups entirely.

I thought the analogy would be useful for illustrating points about
resource consumption and so on, but not for evaluating probabilities
or other engineering parameters.

Just to be clear, I am not categorically against bicasting, but I
think it's true realm of applicability is not large enough to be
mandated as part of fast handover protocol, and that there may often
be more economical approaches available.

=> Mandating bicasting was _never_ intended or discussed.
The assumption was always a MAY or a SHOULD. I think 
a MAY is sufficient.

Hesham

---

From: kempf <[email-masked]>
Date: Thu, 2 Aug 2001 15:30:11 -0700 (PDT)

Hesham,

>=> Two points to consider here:
>
>1. What Charlie suggests above IS bicasting
>   except that it is not explicitly requested by 
>   the MN. There are several issues here that I highlighted
>   on the FMIPv6 list and on this list earlier. 
>

Well, yes, to the extent that the buffered packet is sent down
both links.

>2. How do you know the MN has detached ?? Is this 
>   a generic assumption ? The answer is you don't 
>   know on all link layers and it is not a generic
>   assumption.
>

In general, smoothing is necessary IMHO when you only have L3 information or 
coarse gained L2 information about handover sequencing. For example, if the only 
information you have to go on about when handover begins is the receipt of a 
HACK, then you need to bicast or buffer for a long period, until the MN begins 
DAD or sends a F-BU on the new AR, and the probability is that your user will 
notice (i.e. dropped or duplicated packets for bicasting, propagated latency for 
buffering) because of the side effects of handover smoothing. If you have finer 
grained L2 sequencing information about handover, you can forget smoothing 
altogether, or only buffer or bicast for a very short time period. For example, 
if old AR gets a Link Drop L2 trigger on L2 handover and new AR gets a Link 
Active trigger when the mobile appears, old AR can stop sending packets down the 
old L2 as soon as L2 handover begins and start tunneling them to the new AR. The 
new AR can then either buffer or drop the packets until it gets the Link Up 
trigger with the mobile's L2 address, when it starts delivery. Thus, there is 
only a very short window during which L2 is completely unavailable when 
smoothing (if any) is needed.

This is why getting requirements (i.e. draft-manyfolks-mobilereq-l2-00.txt) and 
possibily an API and/or protocol for L2 triggers is so important. Without proper 
L2 sequencing information, it won't be possible to provide high quality real 
time flows across handovers.

		jak

---

From: kempf <[email-masked]>
Date: Thu, 2 Aug 2001 15:39:07 -0700 (PDT)

Charlie,

>Second, if our buffering scheme fits your definition of bicasting,
>then it seems to me that we ought to work together to fashion a
>smooth-handover draft that covers all the bases.
>

Outstanding idea! A joint smoothing draft with both and some
analysis would be a real benefit.

We just need to figure out where everybody can agree,  and also
I think data on some experiments is needed to validate intuition.

		jak

---

From: [email-masked]
Date: Mon, 6 Aug 2001 18:02:55 -0700

Hello James,

Along your theory of reducing signalling over air interface, how does the BUs
sent out from MN after a new CoA. Does MN send individual BUs to all CNs that it
is talking during hand off?

I mean, if the MN has "m" CNs, then there will be "m" BUs per CN. Is there a
way, a HA can act as splitter and relay for BUs.

Barani.

---

From: James Kempf <[email-masked]>
Date: Mon, 6 Aug 2001 23:42:55 -0700

Hi Barani,

>is talking during hand off?

The MN has to send out BUs only if it changes its CoA so it can reduce
signalling by not changing its CoA unless it has time. Once it decides
to change its CoA, the number of BUs will depend on whether or not
there are any outstanding CNs. The MN may wait until there are no
outstanding CNs, in which case it must only send a BU to the HA. 
If there are CNs, the presence or absence of LMM will determine
how many BUs need to be sent.

>way, a HA can act as splitter and relay for BUs.

I don't follow. Unless it piggybacks, the MN must send one BU per CN/CoA, or?
Assuming it has one CoA, then it must send one BU per CN, plus one to
the HA.

		jak