Subject: RE: [mobile-ip] Re: So what is bicasting vs. buffering

From: "Gary Kenward" <[email-masked]>
Date: Fri, 3 Aug 2001 00:09:49 -0400

Interesting discussion.

But it seems to me that there is something missing with the
distinguishment being drawn between "buffering" and "bicasting".
It may be subtle, but here goes: To me, when you buffer something
you explicitly store it for future forwarding. This would be in
addition to any usually queuing delay. The idea behind bicasting
is to forward the packets as soon as possible after they arrive.

To make the distinction real, if the stream in question is EF,
bicasting would maintain the forwarding delay bounds at both ARs.
What happens the packets after they are forwarded is a different issue,
and related to the discusson about dropped vs duplicated packets. 
When you buffer the EF stream, by my interpretation, are unlikely to
fulfill a realistic EF bound, because you are buffering simply to hold
the packets for future delivery, which adds delay, period.

I realize I could be opening up a few bulk size cans of worms here.
To me, the reason you bicast is to avoid delaying packets. I personally
do not see duplicates as evil (but they must be removed at the reciever,
and not by TCP - at least, the existing TCP).

Gary

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: August 2, 2001 18:57
To: Hesham Soliman (ERA)
Cc: 'Pat Calhoun '; [email-masked] ' ';
[email-masked] ' '; [email-masked] ' '
Subject: [mobile-ip] Re: So what is bicasting vs. buffering

ok, so then the options are:

1. mobile initiated (mn signalling over the air)
2. network initiated (no over the air signalling)

and

1. don't buffer on NewAR
2. buffer on NewAR

So, it is always bicasting, but some proposals use different mixes
of the alternatives above.

PatC
On Fri, Aug 03, 2001 at 12:40:51AM +0200, Hesham Soliman  (ERA) wrote:
>  
> So in my mind, I believe that the main difference between the bicasting
> and buffering approaches is simply that the latter requires the mobile
> to *request* packets.
> 
> Am I right?
> 
> => Not at all :)
> The proposal that Charlie mentioned IS bicasting
> that is the point I'm trying to make. 
> I don't understand why people assume that if you bicast 
> then by definition you can't buffer. You can
> delay packets destined to the new AR/FA based on some 
> calculations of the average time for a handover. 
> 
> In addition you can bicast without a request from the 
> MN (ie. by default in the AR). 
> However, if you say I will send packets to the MN
> at the current AR and send another copy to the new
> AR then you ARE bicasting but just don't want to
> say the word :))))))))
> It doesn't matter how long you buffer or delay the 
> packets destined to the new AR you are still sending
> TWO copies. 
> 
> There are hidden assumptions if you do it by default 
> in the AR though (without the MN's request). The 
> assumption is that you know when the MN disconnects.
> This is not generic of course so you still need 
> to allow for the option of the MN requesting bicasting.
> 
> 
> Hesham

---

From: Wolfgang Schoenfeld <[email-masked]>
Date: Fri, 03 Aug 2001 15:59:57 +0200

Gary,

> Gary Kenward wrote:

I agree (and usually regret that, since I live in a different time zone,
it is hard for me to synchronize with such discussions).

> the packets for future delivery, which adds delay, period.

Please remember that mobility means to change connectivity.
Hence, it may simply the case that, when your data arrive at the (old or new)
access router, the link is just down. You can nothing do but buffering
in the hope that the link will come up again.

> and not by TCP - at least, the existing TCP).

For a better understanding of the  problem,
I practiced a little bit with Charlie Perkin's pizzas
(in Phil Neumiller's business model, with slight modifications).
And I arrived at:

1. Bicasting may make sense without buffering.
2. Buffering may make sense without Bicasting.
3. Both may complement each other.

Assume that you have to serve one pizza P to one dignitary D
which moves through your city. The city is ful of your kiosks
where you can deliver P within a certain range.

If you know D's itinerary in advance and where she will be when,
you can do some (not easy) computations for timely delivery,
taking speed both of P and D into account.
Neither bicasting nor buffering is needed.

Now assume that you only know the itinerary.

If the delivery ranges of kiosks along the itinerary overlap,
you may multicast P along it.
If all copies of P arrive at their respective kiosk at one and the same time,
then at least one copy reaches D in time, i.e. without buffering.
Hence 1.

If delivery ranges do not overlap,
you have to both multicast and buffer.
Hence 3.

Finally, assume that you only know for sure one kiosk
where D will pass by.
Then you unicast P there, and it has to be buffered.
Hence 2.

Note that the latter case seems quite common
whereas 1. is rather artificial.

Does this help? Did I make a mistake? I never delivered a single pizza...

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