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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 31 Jul 2001 01:43:40 +0200

Hello Wolfgang,

> to a certain extend, I understand your impatience -
> you want to go on with your idea.
> But let me, in order to illustrate the gravity of the situation,
> develop an analogy:
> 
	=> Sorry if I appeared impatient, I didn't want to give 
	that impression, the impression I wanted to give was
	frustration because I think we're discussing secondary
	issues (like which doc it should go in) or going around 
	in circles on the technical side (like "it's bad for TCP", 
	"but here's a fix", "but it's bad for TCP" !!!! ..etc)
	I'm not blaming anyone, just hoping that we solve first
	things first. 
	- Acknowledge that there is a problem (already partially mentioned
	  in FMIPv6)
	- Agree on a solution 

> Assume that you have a gun
> 
	=> OK ! I'm not familiar with them but I'll do my best :)

> and you want to shoot a bullet (i.e. data packet) to a target.
> If the target is stationary - no problem.
> If it is mobile, you have to perform quite complicated computations
> which take velocity of bullet 
> and velocity as well as direction of target into account.
> 
> Since you don't know the latter (neither the former),
> 
	=> Well the assumption is that we do know where the 
	target is going. This is the assumption in both FMIPv4
	and FMIPv6. Otherwise we would have to use multicast.
	Hold your fire !

> you may take a machine gun which produces
> lots of copies of the bullet/packet.
> Obviously, this increases the probabilty that you hit the target.
> 
> 
> Alternatively, you may introduce 'redirection guns'
> which intercept your packet
> and redirect it to some new position of the target.
> Or you may use retardation devices
> to hold back the packet if it is too early.
> 
	=> The problem is exactly that (the redirection). 
	How do you know when to redirect. Once notified (BU), 
	you can not assume that you can immediately
	redirect. There is a gap here in which the target 
	may still be connected to the oAR or disconnected
	then came back, or never disconnected at all (failure).

> (Maybe, there are acceleration devices, too.)
> You may also combine all these mechanisms into 'enhanced machine guns'.
> And the final solution would be to 'broadcast' everywhere -
> at least one bullet/packet would reach the target in any case.
> 
> Well, you can do that.
> However, because of possible collateral damages,
> you have to carefully analyze what you are doing.
> 
	=> Agreed

> Where is such an analysis?
> 
	=> There is a theoritical one in the draft and I've pointed to a 
	practical one earlier. I do agree 100 % with doing as much 
	analysis as possible, however I also like consistency. 
	Inconsistency causes frustration and confusion. 
	For example, where is the analysis that Fast Handoffs 
	will work at all ? More importantly where is the theoritical
	analysis that contradicts the existing one in the draft ?

> Note that an analysis is the harder
> the more complicated your mechanism is.
> You have to take into account not only velocity and direction of the bullet,
> but also the effects of all the intermediate devices.
> 
	=> This is not something we can do for a standard. We will
	never be able to analyse all situations for all link layers 
	that exist. System designers need to optimise the "tool sets"
	provided according to their respective systems. 

	Note also that analysis you mention below is also more
	relevant to the concept of Fast handoffs in both drafts. 

> Do you really believe that 'practical tests' are sufficient?
> 
	=> I think it's a pretty good start. The more the better 
	of course. 

	Regs,
	Hesham

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 30 Jul 2001 17:26:41 -0700

> 	- Acknowledge that there is a problem (already partially mentioned

Sure, but some folks will not agree on a solution because all they
see is that bicasting doesn't work because of a problem with TCP that
is being addressed. My intention is to try to get that issue out of
the way so we can discuss actual solutions.

It is rather difficult to discuss solutions, when folks cannot agree
that one proposed alternatie is in fact a solution due to some
perceived problem

PatC

---

From: Wolfgang Schoenfeld <[email-masked]>
Date: Tue, 31 Jul 2001 11:51:38 +0200

Hesham,

I accept nearly all you are saying :-)
Few comments below.

Regards
Wolfgang

> ...

>         then came back, or never disconnected at all (failure).

Yes, even if you have precise knowledge of the mobile's moves
(and even of how link layer connectivity develops)
you may be unable to compute from that knowledge when to redirect where
because there are much more sources for uncertainty.
But you will agree in that we should do our best here
and rely to bi-/multicasting only if other means fail.
(BTW, in my picture, I should have used 
a usual gun with pellets instead of machine gun.)

> ... 

>         For example, where is the analysis that Fast Handoffs

There is none, as far as I can see :-(

>         never be able to analyse all situations for all link layers

Unfortunately, you are right.

> ... 

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