Subject: Bicasting/Simultaneous bindings in charter (was RE: [Mipshop] Warning: Bicasting and FMIPv6)

From: "Karim El-Malki (AL/EAB)" <[email-masked]>
Date: Fri, 12 Aug 2005 16:55:59 +0200

Hi
I don't know the IPR details and the author (Reiner Ludwig)
is away. However Gabriel mentioned this to me in Paris and
we are looking into it. In any case, whatever solution is
adopted for better TCP performance, I think that the bicasting
(simultaneous bindings) issue has come up a few times now
and that there seem to be people interested in working on it.
So I would suggest to include bicasting as a handoff optimisation
technique in the new charter, starting from a problem
statement which can be done rather quickly. We can then
find the best solution, including TCP considerations.
I'd like to know if people think this is acceptable.
Rgds,
Karim

-----Original Message-----
From: [email-masked]
To: [email-masked]; [email-masked]
Sent: 12/08/2005 2.49
Subject: RE: [Mipshop] Warning: Bicasting and FMIPv6

Greg, 

I think to be fair to the people that developed
Eifel or sent the charges for the IPR (I'm sure none
of them is on this list to defend themselves) we would
need to know a lot more detail than that to dismiss
Eifel. Like, who is this implementer?? was it a commercial
implementation? 
Of course an IPR holder has every right to demand payment
for a commercial implementation. My understanding is 
that the IPR statement for EIfel is RAND, which is 
widely accepted in IETF. 

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On
 > Behalf Of Greg Daley
 > Sent: Thursday, August 11, 2005 8:40 PM
 > To: [email-masked]
 > Subject: [Mipshop] Warning: Bicasting and FMIPv6
 > 
 > 
 > Dear Mipshop,
 > 
 > I posted about this recently, but it was lost in the noise.
 > 
 > I was at the TCPM WG session where they were discussing
 > a draft recommending TCP implementation practices.
 > 
 > During the session, there was consensus to move the Eifel
 > algorithm, to an experimental section of the document
 > _because_ it has not been widely deployed and because
 > of existing uncertainties regarding IPR.
 > 
 > What was discussed in the session was the occurrance of
 > an implementor being presented with a schedule of
 > charges for licenses by an IPR holder.
 > 
 > Eifel has been described as a way to handle
 > packet duplication events experienced due to bicasting
 > in the draft (section 10):
 > 
 > http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bi
casting-v6-06.txt

While the IETF (in compliance with its policy: BCP 79)
will not take a position on the validity of the IPR claims,
please be aware that Eifel is not widely implemented,
and isn't likely to be implemented by default in TCP
stacks, due to its experimental nature.

If bicasting is important, it may be worth investigating if
another mechanism is available for reducing the effect of
duplicated packets on upper layer protocol stacks.

Greg

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

===========================================================
This email may contain confidential and privileged material for the sole
use
 of the intended recipient.  Any review or distribution by others is
strictly
 prohibited.  If you are not the intended recipient please contact the
sender
 and delete all copies.
===========================================================

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 17:22:50 +0200

Karim El-Malki (AL/EAB) wrote:

> technique in the new charter, starting from a problem statement which
>  can be done rather quickly.

I am supportive for discussing/writing/reviewing a problem statement for
FMIPv6, that should include user-experience of how Mobile IPv6 is slow
and why.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Aug 2005 08:58:03 -0700

Karim,

I'd like to see some experimental evidence comparing using bicasting to not
using it before putting this into the MIPSHOP charter. Are there any papers
that you or others have published in this area?

            jak

----- Original Message -----
From: "Karim El-Malki (AL/EAB)" <[email-masked]>
To: "Soliman, Hesham " <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, August 12, 2005 7:55 AM
Subject: Bicasting/Simultaneous bindings in charter (was RE:
[Mipshop]Warning: Bicasting and FMIPv6)

Hi

-----Original Message-----
From: [email-masked]
To: [email-masked]; [email-masked]
Sent: 12/08/2005 2.49
Subject: RE: [Mipshop] Warning: Bicasting and FMIPv6

Greg,

Hesham

casting-v6-06.txt

Greg

---

From: "Karim El-Malki (AL/EAB)" <[email-masked]>
Date: Fri, 12 Aug 2005 18:35:46 +0200

Here is a Mobicom 2003 paper with evidence of bicasting performance
improvements:
http://mobqos.ee.unsw.edu.au/mobqos/papers/ID53_p0307-hsieh-e1.pdf
Since a MN depends on triggers like WLAN scans it may move at any
time after having sent a FBU (or BU) or it may not move at all.
The triggers are often only hints of likely movement e.g. a signal
from a new base station becoming stronger. So the MN may be
connected to the old AR for a significant amount of time after
sending a FBU and before actually starting L2 handoff. The amount of
time depends on the L2 but it is certainly >0. If the L2 handoff
never takes place then the amount of time may be significant. This
means that a certain disruption will always be there for that amount
of time. To solve this problem, the MN needs to keep on receiving
packets for that period of time at the old AR. There is an
analytical calculation of these timings in the appendix of the
bicasting draft at the link below. That's the problem I would
like MIPSHOP to solve since it affects FMIPv6 (as well as FMIP/HMIP
combinations).
Rgds,
Karim

-----Original Message-----
From: James Kempf
To: Karim El-Malki (AL/EAB); Soliman, Hesham ; [email-masked]; [email-masked]
Sent: 12/08/2005 17:58
Subject: Re: Bicasting/Simultaneous bindings in charter (was RE: [Mipshop]Warning: Bicasting and FMIPv6)

Karim,

I'd like to see some experimental evidence comparing using bicasting to
not
using it before putting this into the MIPSHOP charter. Are there any
papers
that you or others have published in this area?

            jak

----- Original Message -----
From: "Karim El-Malki (AL/EAB)" <[email-masked]>
To: "Soliman, Hesham " <[email-masked]>;

Hi

-----Original Message-----
From: [email-masked]
To: [email-masked]; [email-masked]
Sent: 12/08/2005 2.49
Subject: RE: [Mipshop] Warning: Bicasting and FMIPv6

Greg,

Hesham

casting-v6-06.txt

Greg

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 20:05:21 +0200

Karim El-Malki (AL/EAB) wrote:

> time after having sent a FBU (or BU) or it may not move at all. The 
> triggers are often only hints of likely movement e.g. a signal from a
>  new base station becoming stronger. So the MN may be connected to
> the old AR for a significant amount of time after sending a FBU and 
> before actually starting L2 handoff. The amount of time depends on 
> the L2 but it is certainly >0. If the L2 handoff never takes place 
> then the amount of time may be significant. This means that a certain
>  disruption will always be there for that amount of time. To solve 
> this problem, the MN needs to keep on receiving packets for that 
> period of time at the old AR. There is an analytical calculation of 
> these timings in the appendix of the bicasting draft at the link 
> below. That's the problem I would like MIPSHOP to solve since it 
> affects FMIPv6 (as well as FMIP/HMIP combinations).

The problem mentioned could be solved by always doing IP stuff after
link-layer stuff, but faster than it's currently done.  Like
autoconfiguring an address after the link-layer is fine, but do it with
less and shorter messages.

It may be possible that doing all messaging after attachment is not as
bad as imagined, and maybe better than doing simultaneous things in a
pipeline manner.  Because I doubt the pipeline a designer is imagining
has strict rules, strict rigid limits.  A mobile moves (moving in and
out of neighbouring coverages) guided by its human user, not by some
message sent.

Alex

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 12 Aug 2005 23:49:30 +0530

> less and shorter messages.

This is the DNA job.
http://www.ietf.org/internet-drafts/draft-pentland-dna-protocol-01.txt

But I am sure the DNA has never thought, it can do better than FMIP.
We have a draft how DNA and FMIP co-work
http://www.ietf.org/internet-drafts/draft-koodli-dna-fmip-00.txt
This is very small draft, 7 pages (including everything).

In this draft we still reatined the HI/HACK, and there was question on this
in DNA list why we need HI/HACK.
http://webcamserver.eng.monash.edu.au/~warchive/dna/2005-07/msg00062.html

-Syam

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Aug 2005 11:29:45 -0700

This paper isn't very convincing. The authors proposed bicasting in a
previous paper, but seem to be retracting it in Section 3:

    While it has been shown in [8] that S-Mip provides a well
    composed solution, in providing a seamless handoff,
    we believe there still exist some deficiencies, within the
    framework. <here a discussion of duplicate packet
    delivery from bicasting and the problems it causes
    for TCP due to duplicate packet delivery>

    In what follows, we elaborate on our solution. ...
    Upon sending the F-BU message to the PAR,
    the MN *must* immediately switch to the NAR. Furthermore,
    the PAR *must* immediately forward packets to the NAR
    after recdeiving the F-BU. ...

In other words, this paper seems to be advocating a modification of the
author's previous algorithm to remove bicasting, unless I'm missing
something.

            jak

----- Original Message -----
From: "Karim El-Malki (AL/EAB)" <[email-masked]>
To: "James Kempf " <[email-masked]>; "Soliman, Hesham "
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, August 12, 2005 9:35 AM
Subject: RE: Bicasting/Simultaneous bindings in charter (was RE:
[Mipshop]Warning: Bicasting and FMIPv6)

-----Original Message-----
From: James Kempf
To: Karim El-Malki (AL/EAB); Soliman, Hesham ; [email-masked];
[email-masked]
Sent: 12/08/2005 17:58
Subject: Re: Bicasting/Simultaneous bindings in charter (was RE:
[Mipshop]Warning: Bicasting and FMIPv6)

Karim,

            jak

----- Original Message -----
From: "Karim El-Malki (AL/EAB)" <[email-masked]>
To: "Soliman, Hesham " <[email-masked]>;

Hi

-----Original Message-----
From: [email-masked]
To: [email-masked]; [email-masked]
Sent: 12/08/2005 2.49
Subject: RE: [Mipshop] Warning: Bicasting and FMIPv6

Greg,

Hesham

casting-v6-06.txt

Greg

---

From: "Karim El-Malki (AL/EAB)" <[email-masked]>
Date: Fri, 12 Aug 2005 20:40:30 +0200

I am talking about a different problem in this thread.
There is an uncertainty about when the L2 handoff will
occur compared to the time when FBU is sent. This
will exist in most cases (e.g. WLAN) and causes a
disruption. That disruption will be considerable in
cases where L2 triggers based on signal strengths are
used (e.g. WLAN) since the MN may never actually make
a L2 handover or take a long time before it moves.
/Karim

-----Original Message-----
From: Syam Madanapalli
To: Alexandru Petrescu
Cc: Karim El-Malki (AL/EAB); Soliman, Hesham; [email-masked]; James Kempf; [email-masked]
Sent: 12/08/2005 20:19
Subject: Re: Bicasting/Simultaneous bindings in charter (was RE: [Mipshop]Warning: Bicasting and FMIPv6)

This is the DNA job.

In this draft we still reatined the HI/HACK, and there was question on
this
in DNA list why we need HI/HACK.
http://webcamserver.eng.monash.edu.au/~warchive/dna/2005-07/msg00062.htm
l

-Syam

---

From: "Karim El-Malki (AL/EAB)" <[email-masked]>
Date: Fri, 12 Aug 2005 21:22:22 +0200

The authors of that paper propose a further improvement S-MIP:
a mechanism where handover time prediction is close to exact by
using network determined handoff through movement tracking and
triangular signal strength evaluation. I don't think we need
to consider this in our discussion here in the MIPSHOP list
though it is interesting. However there is a comparison table
between MIP6, FMIP, FMIP+HMIP and with bicasting. There is
also a discussion. These results show that bicasting improves
e.g. FTP transfer speeds compared to standard MIP6 or FMIP.
What I am trying to say is that we need to solve a problem,
which is the uncertainty between L2 handover time and the
time at which the FBU is sent. I think we can get a good grip
on the problem quickly since it is relatively straight forward.
In the following step we look at the solution. Simultaneous
bindings are an obvious solution to consider. You may have
other mechanisms in mind which can be discussed.
/Karim

-----Original Message-----
From: James Kempf
To: Karim El-Malki (AL/EAB); Soliman, Hesham ; [email-masked]; [email-masked]
Sent: 12/08/2005 20:29
Subject: Re: Bicasting/Simultaneous bindings in charter (was RE: [Mipshop]Warning: Bicasting and FMIPv6)

            jak

----- Original Message -----
From: "Karim El-Malki (AL/EAB)" <[email-masked]>
To: "James Kempf " <[email-masked]>; "Soliman, Hesham "
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, August 12, 2005 9:35 AM
Subject: RE: Bicasting/Simultaneous bindings in charter (was RE:
[Mipshop]Warning: Bicasting and FMIPv6)

-----Original Message-----
From: James Kempf
To: Karim El-Malki (AL/EAB); Soliman, Hesham ;
[email-masked];
[email-masked]
Sent: 12/08/2005 17:58
Subject: Re: Bicasting/Simultaneous bindings in charter (was RE:
[Mipshop]Warning: Bicasting and FMIPv6)

Karim,

            jak

----- Original Message -----
From: "Karim El-Malki (AL/EAB)" <[email-masked]>
To: "Soliman, Hesham " <[email-masked]>;

Hi

-----Original Message-----
From: [email-masked]
To: [email-masked]; [email-masked]
Sent: 12/08/2005 2.49
Subject: RE: [Mipshop] Warning: Bicasting and FMIPv6

Greg,

Hesham

casting-v6-06.txt

Greg

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 21:28:50 +0200

Karim El-Malki (AL/EAB) wrote:

> I am talking about a different problem in this thread. There is an 
> uncertainty about when the L2 handoff will occur compared to the time
>  when FBU is sent. This will exist in most cases (e.g. WLAN) and 
> causes a disruption. That disruption will be considerable in cases 
> where L2 triggers based on signal strengths are used (e.g. WLAN) 
> since the MN may never actually make a L2 handover or take a long 
> time before it moves.

I think the last assumptions are right.

About the paper.

It looks as a typical paper with a nice conceptual overview, comparison
of competitor approaches and winner declared at the end, which is
obviosuly that author's oppinion.  As many other papers, it also
mistakenly names "experiments" the ns-2 "simulations".

Let me cite from the paper:

> S-MIP uses signal strength together with triangulation to track the 
> MN’s location [8], and determine its movement pattern. The entity 
> which stores the history of the locations and determines the movement
>  pattern, referred to as the Decision Engine (DE), is similar to

Would the authors acknowledge that interpolation (determining a future
value from a sequence or prior values) is something very hard to do?
Would the authors acknowledge that a mobility pattern is impossible to
determine by any computer, even if called Decision Engine?  Would the
authors acknowledge that mobile people is more like "Brownian Movement"
and less like a missile trajectory?

> From the movement pattern, the DE decides whether i) the MN is moving
>  linearly, ii) the MN is moving stochastically (including ping-pong)

Would the authors acknowledge that nobody knows how to generate a truly
random number, and even less how to recognize that an ongoing sequence
has random values?  How could ever a computer determine what's random if
even humans can't.

Would the authors acknowledge that even if we knew how to do it, then
not only the Fast Mobility problems would be solved with Decision
Engines but also e-commerce codes would be easily cracked and so on.

Finally, if the paper had any little form of actual experimental
results, be it implementation (kernel Ooops, bit order), or measurements
of any kind of wireless link-layer, or actually observed mobility
patterns, or user-experience of users realplaying, skype'ing,
complaining about interruptions due to Mobile IP, then
much more help it could have been to design a useful protocol.

Alex