Subject: [Mipshop] Re: FMIPv6 FBU lifetime

From: yechengping <[email-masked]>
Date: Wed, 26 Apr 2006 08:42:41 +0800

Hi Wassim H.
	if the lifetime be set to a fixed value in FMIPv6,this will
astrict FMIPv6's application in handover area.Of cause in some area the
lifetime often is fixed value .

BR
Chengping Ye

Message: 1
Date: Tue, 25 Apr 2006 04:49:32 +0300 (EEST)
From: Wassim Haddad <[email-masked]>
Subject: [Mipshop] FMIPv6 FBU lifetime
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

Is there any particular reason why the binding lifetime is not
(cannot) be set to a fixed value in FMIPv6?

Regards,

Wassim H.

------------------------------

Message: 2
Date: Mon, 24 Apr 2006 19:03:02 -0700
From: Vijay Devarapalli <[email-masked]>
Subject: Re: [Mipshop] FMIPv6 FBU lifetime
To: Wassim Haddad <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Wassim Haddad wrote:
> Hi,
> 
> Is there any particular reason why the binding lifetime is not
> (cannot) be set to a fixed value in FMIPv6?

it *should* be a configurable value on the mobile
node. the PAR can ofcourse be configured with a
maximum lifetime.

Vijay

------------------------------

Message: 3
Date: Tue, 25 Apr 2006 06:20:07 +0300 (EEST)
From: Wassim Haddad <[email-masked]>
Subject: Re: [Mipshop] FMIPv6 FBU lifetime
To: Vijay Devarapalli <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 24 Apr 2006, Vijay Devarapalli wrote:

> > Is there any particular reason why the binding lifetime is not
> > (cannot) be set to a fixed value in FMIPv6?
>
> it *should* be a configurable value on the mobile
> node.

> the PAR can ofcourse be configured with a
> maximum lifetime.

=> It is not enough to have such value?

Wassim H.

------------------------------

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

End of Mipshop Digest, Vol 24, Issue 13
***************************************

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

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 26 Apr 2006 04:00:19 +0300 (EEST)

> lifetime often is fixed value .

=> Am not sure if I fully understand your comment but IMHO using FMIPv6
should also be justified (i.e., worthy) and when it is justified then a
"large enough" value can be set by the AR to cover all "realistic"
scenarios.

Regards,

Wassim H.

---

From: yechengping <[email-masked]>
Date: Wed, 26 Apr 2006 09:42:02 +0800

Hi 
	If a "large enough" value be set to cover all "realistic"
scenarios now, perhaps in the future some application that  need a
larger value than the "large enough" value  will not  be execute I
think. If the "large enough" value is very large, Security  must be
carefully Considered.

BS
Chengping Ye

-----邮件原件-----
发件人: Wassim Haddad [mailto:[email-masked]] 
发送时间: 2006年4月26日 9:00
收件人: yechengping
抄送: [email-masked]
主题: Re: [Mipshop] Re: FMIPv6 FBU lifetime

On Wed, 26 Apr 2006, yechengping wrote:

> if the lifetime be set to a fixed value in FMIPv6,this will astrict 
> FMIPv6's application in handover area.Of cause in some area the 

Regards,

Wassim H.

> [email-masked] https://www1.ietf.org/mailman/listinfo/mipshop
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 00:03:09 +0200

Wassim Haddad wrote:
> => Am not sure if I fully understand your comment but IMHO using 
> FMIPv6 should also be justified (i.e., worthy) and when it is 
> justified then a "large enough" value can be set by the AR to cover 
> all "realistic" scenarios.

It's clear that FMIPv6 is not much worth if the underlying link layer 
acts stupidly.  And if the underlying link acts correctly it _may_ be 
that FMIPv6 is not needed, depending on what the application needs.

E.g. if the FMIPv6 IP design were entirely translated into wifi
link-layer messaging then we could get very serious speedups for wifi
handovers.  Take the contents of PrRtAdv and put it in wifi 50ms Beacons 
thus no need to do wifi scan (Probe Request/Probe Response on 12
channels every so and so milliseconds).  This will speed things up a lot.

Also, it would be very interesting to see discussions about 
_application_ layer behavior that is improved by the FMIPv6 design.

Alex

---

From: yechengping <[email-masked]>
Date: Fri, 28 Apr 2006 16:08:54 +0800

Hi Alex

	It is necessary to improve havdover latency by using
FMIP.Perhaps In some application,FMIP is not indispensable(e.g. you
given example),but not all applications can't use FMIP,I think. 

BR,
Chengping Ye

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, April 28, 2006 6:03 AM
To: Wassim Haddad
Cc: yechengping; [email-masked]
Subject: Re: [Mipshop] Re: FMIPv6 FBU lifetime

thus no need to do wifi scan (Probe Request/Probe Response on 12
channels every so and so milliseconds).  This will speed things up a
lot.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 13:09:23 +0200

yechengping wrote:
> Hi Alex
> 
> It is necessary to improve havdover latency by using FMIP.

Hi Chengping,

In many instances it is impossible to improve link-layer handover
latency by just using FMIP.  Some wifi drivers will do additional and
non-necessary link-layer operations upon handover without FMIP telling
it to do so.  Worse, there is no other means than bare re-programming
these wifi drivers for better link-layer messaging.

One example of these non-necessary wifi operations is what people call
"scan".  Some drivers will perform link-layer Probe Request/Response to
all access points in the neighborhood, and on all channels (1-12) even
though an upper layer (IP or app) instructs it to attach to a certain AP
MAC address.

> Perhaps In some application,FMIP is not indispensable(e.g. you given
>  example),but not all applications can't use FMIP,I think.

Ok.  Any app can use FMIP.  There are FMIP implementations.  The
question is how much do these apps gain by using FMIP instead of using
just MIP.  There's currently no indication about this.

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 28 Apr 2006 12:22:18 -0700

Hi Alex,

a few comments:

- application performance: yes, the goal is to provide performance for 
real-time applications. This has come up before and perhaps I can refer 
to a few case studies.
a) check out the video showing Tarzan implementation in action. I have 
put it on people.nokia.net/~rajeev/20050427_yrp_short2.mpg (size 24 MB).
b) Vijay and myself did _several_ experiments involving video and VoIP 
over WLAN a few years ago. In fact, we did both FMIP and context 
transfer of header compression state, and measured delay and packet loss 
(with and without FMIP, with and without CT etc.). I can share this with 
interested folks, perhaps at the next IETF.
c) Charlie presented the delay bar graphs with FMIP a few IETFs ago at 
the MIP4 meeting.
d) fmipv6.org folks have mentioned they found the performance for their 
application(s).

- link coupling: yes, this is recognized in FMIP. Hence, we have FMIP 
over WLAN, FMIP over 802.16e, FMIP over 3gcdma. The archives should have 
a long thread on "scan" and "join" latency. Folks have used hostAP 
driver and mad wifi to integrate the protocol.

- why not just use MIP? Folks are free to use whatever works for them. 
For that matter, folks could argue the same for other protocols as well 
(SIP Mobility will do it, why need MIP etc.?). As the protocol states, 
delays from movement detection, IP configuration and Binding Update in 
MIP affect real-time applications. FMIP addresses that from a networking 
layer standpoint. There are implementations supporting that claim. So, 
perhaps it is best to spend our time here on what we can do to improve 
the specification.

Thanks,

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 22:49:38 +0200

Rajeev Koodli wrote:
> 
> Hi Alex,
> 
> a few comments:
> 
> - application performance: yes, the goal is to provide performance 
> for real-time applications. This has come up before and perhaps I can
>  refer to a few case studies.

> a) check out the video showing Tarzan implementation in action. I 
> have put it on people.nokia.net/~rajeev/20050427_yrp_short2.mpg (size
>  24 MB).

I'm curious, I'll have a look at it, thanks.  But can we have a
technical discussion here?  Is that video the holy grail of FMIPv6
motivation?  Could you add it in the FMIPv6 motivation section...

Does that video show how better FMIPv6 is compared to MIP6 for a user?

> b) Vijay and myself did _several_ experiments involving video and 
> VoIP over WLAN a few years ago. In fact, we did both FMIP and context
>  transfer of header compression state, and measured delay and packet
>  loss (with and without FMIP, with and without CT etc.). I can share
>  this with interested folks, perhaps at the next IETF.

Wonderful if you could share that and discuss technically about it.

We've also performed lots of WiFi measurements here but I can't really
share data publicly.  I could however share experience about how WiFi
acts.  So that's good.

> c) Charlie presented the delay bar graphs with FMIP a few IETFs ago 
> at the MIP4 meeting.

YEs, I remember the presentation, I'll have to look over it again.  I
even exchanged questions/answers on the mike...

> d) fmipv6.org folks have mentioned they found the performance for 
> their application(s).

Last time I've checked fmipv6.org there was still no code available.
And now it seems down (click here: http://www.fmipv6.org).  Yes, they've
mentioned interesting things about WiFi behaviour.

>  over WLAN, FMIP over 802.16e, FMIP over 3gcdma.

Yes, that's a good thing to separate the problems.  I'm only thinking
FMIP over wifi.  MIP between wifi and (cdma or 16e) is instantaneous, no
possible improvement.

> The archives should have a long thread on "scan" and "join" latency.
>  Folks have used hostAP driver and mad wifi to integrate the
> protocol.

They've never answered this: if they modify hostap and mad wifi but
don't modify MIPv6, will the handovers be better?  I guess the answer is
yes (but never tried).

> - why not just use MIP? Folks are free to use whatever works for 

I agree with you here, me too.

> For that matter, folks could argue the same for other protocols as 
> well (SIP Mobility will do it, why need MIP etc.?).

Well not quite the same.  MIP and SIP really have different goals.  SIP
can't really offer session continuity at permanent IP address, over
worldwide Internet.  FMIP and wifi optimizations intersect somehow their
goals at some point: improve handover latency.  I'm only referring to 
FMIP and wifi.

> As the protocol states, delays from movement detection, IP 
> configuration and Binding Update in MIP affect real-time 
> applications. FMIP addresses that from a networking layer standpoint.
>  There are implementations supporting that claim. So, perhaps it is 
> best to spend our time here on what we can do to improve the 
> specification.

Ok, that is a good generic goal for advancing the document.

Other (maybe few) people who intend to improve wifi handover latencies
do however know that it can be achieved by improving wifi behaviour.
FMIPv6 is not a panacea to wifi problems, simply because it runs above wifi.

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 28 Apr 2006 15:19:34 -0700

> motivation?  Could you add it in the FMIPv6 motivation section...

I thought you asked for application level performance. So, I was 
providing some case studies I am aware of. And, just that.

> Does that video show how better FMIPv6 is compared to MIP6 for a user?

You can try it yourself. Again, folks are free to make their own choices.

> mentioned interesting things about WiFi behaviour.

I browsed the code couple of weeks ago on their website.

> don't modify MIPv6, will the handovers be better?  I guess the answer is

Well, hostap and mad wifi provide tools to control scan latency (more 
specifically, hostap allows manual re-association with a previously 
scanned AP). They don't solve the movement detection, IP configuration 
and binding update (including RR) latencies at L3.

> goals at some point: improve handover latency.  I'm only referring to 

My point was that folks can build solutions based on their target 
environements and protocols of their choice. So, in some instances 
someone may argue that SIP Re-Invite will do it for them. (Of course 
agree with what SIP does, MIP does etc.)

I would like to also mention again that a)wifi-specific latencies are 
best solved via approaches such 802.11r and/or host-specific tools such 
as hostap and mad wifi, and b) FMIP is meant to address L3 delays over 
different links (I am not saying across heterogeneous links, 
necessarily) while recognizing the idiosyncracies of each such link.

>> configuration and Binding Update in MIP affect real-time applications. 
>> FMIP addresses that from a networking layer standpoint.

Good.

> FMIPv6 is not a panacea to wifi problems, simply because it runs above 

I agree with you simply because FMIP was/is not designed to solve wifi 
problems. It cannot. I am also aware that there is work in IEEE 
addressing wifi issues.

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 29 Apr 2006 00:48:10 +0200

> providing some case studies I am aware of. And, just that.

Again, thanks for that.  Downloading takes time.  For now I can only see
some trajectory and green landscape in some parking.  I'll come back
when I see it fully,

>>  don't modify MIPv6, will the handovers be better?  I guess the 
>> answer is yes (but never tried).
> 
> scanned AP).

That's a good thing, it speeds wifi things up a lot.  So I'm wondering,
when this scan latency is avoided, and only MIP is used, is the app
performance same as using FMIP?

> agree with what SIP does, MIP does etc.)

Right.

>  best solved via approaches such 802.11r and/or host-specific tools 
> such as hostap and mad wifi, and b) FMIP is meant to address L3 
> delays over different links (I am not saying across heterogeneous 
> links, necessarily) while recognizing the idiosyncracies of each such
>  link.

I agree.  But FMIP is still making assumptions about both oAR and nAR.
If two APs (one running 802.11r and one not) won't offer fast link-layer
handovers I don't think FMIP can.  I mean, the slowest attachment time
to one AP will dominate the entire handover time, whatever FMIP does, no?

So to me it looks like this: if two APs (old, new) run some advanced
WLAN technology then handovers will be fast.  If only one of them runs
it, then FMIP can't help.  FMIP itself can't speed up some WLAN
attachment implementation, whatever it does.  Parameterizing and
improvement (hostap, and "mad" stuff) of some AP _can_ speed up
handovers.  Handovers are nothing else than a sequence of attachments.

I mainly agree with you about advancing the FMIP document.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 29 Apr 2006 01:41:21 +0200

> providing some case studies I am aware of. And, just that.

Rajeev, thanks for providing the video at
http://people.nokia.net/~rajeev/20050427_yrp_short2.mpg

In short, it is a movie showing the video presumably streamed from
driver's wheel to some fixed server.  The app used seems to be voice and
video streaming (vic or vlc or ffmpeg stuff), but we see and hear only
one stream (car sends to fixed server video of and driver's speech).
Driver seems to count in Japanese, driver seat is left and he drives on
the right.  This must be happening in Japan.  The upper left corner of
the video shows inset the "live" car trajectory marked by black dots -
about 8 Access Points.  The active one to which the car is attached is
in red.  Inset is also a small video of the same thing but recorded in
the car.  So one can see the difference in the video/audio smoothness
between what's streamed to the server and what's actually happening in
the car.  Did I get this right?

So there are mainly two running videos: the main and the inset lower
left corner.

The one in the main has sometimes interruptions in video and audio, at
which point the screen says "handover" or "no AP".  The video inset
shows a smoothly running video, no interruption at all.

So, technically what should I understand?  That the inset image is
what's received by server or what's recorded locally in the car?  Or is
the inset image using FMIPv6?

If the difference between the big video and the inset video is only the
use of MIP6 and the use FMIPv6 then I'm impressed - congratulations.  If
the difference is between FMIPv6 with wifi enhancements and FMIPv6 w/o
wifi enhancements I'm not that impressed, because same wifi enhancements
could apply to simple MIP6 as well.

So, I have a technical question: what's the big video and what's the
inset video (in terms of MIP6, FMIPv6 and wifi enhancements)?

Thanks again for providing the video,

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 28 Apr 2006 16:56:34 -0700

> performance same as using FMIP?

At least in our experiments, not using FMIP caused very noticeable delay 
and packet loss (even without RR).

> to one AP will dominate the entire handover time, whatever FMIP does, no?

The MAC operations of the link itself have the effect on overall 
handover. On top of that you have L3 delays. It is the latter that FMIP 
tries to solve while leaving link-specific attributes to be considered 
in the other FMIP-over-X documents.

> handovers.  Handovers are nothing else than a sequence of attachments.

Yes, except that hostap works on the host implementation (although 
specific to prism2 chipsets last I know of).

Good.

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 29 Apr 2006 02:09:15 +0200

Rajeev Koodli wrote:
>> That's a good thing, it speeds wifi things up a lot.  So I'm 
>> wondering, when this scan latency is avoided, and only MIP is used,
>>  is the app performance same as using FMIP?
> 
> At least in our experiments, not using FMIP caused very noticeable 
> delay and packet loss (even without RR).

You mean using MIP caused user-noticeable app delay and using FMIP not?
  On same wifi settings and parameters?  I mean user-noticeable while
using video/whatever app?  That's very interesting.  Frankly speaking
I'm surprised.  Is this experiment that one we see in the video?

I could share my experiences too: when streaming from CN through wifi to
MN, no wifi tweaking, mp3 stream, there's no user noticeable delay, of
course because of buffer.  When streaming same to a small device, over
wifi, no mobility - very many interruptions.

>> I agree.  But FMIP is still making assumptions about both oAR and 
>> nAR. If two APs (one running 802.11r and one not) won't offer fast 
>> link-layer handovers I don't think FMIP can.  I mean, the slowest 
>> attachment time to one AP will dominate the entire handover time, 
>> whatever FMIP does, no?
> 
> handover. On top of that you have L3 delays. It is the latter that 
> FMIP tries to solve while leaving link-specific attributes to be 
> considered in the other FMIP-over-X documents.

YEs, got that.

>> So to me it looks like this: if two APs (old, new) run some 
>> advanced WLAN technology then handovers will be fast.  If only one 
>> of them runs it, then FMIP can't help.  FMIP itself can't speed up 
>> some WLAN attachment implementation, whatever it does. 
>> Parameterizing and improvement (hostap, and "mad" stuff) of some AP
>>  _can_ speed up handovers.  Handovers are nothing else than a 
>> sequence of attachments.
>> 
> 

I think hostap makes a laptop into an AP not STA(?)

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 28 Apr 2006 17:14:56 -0700

I think it is just FMIPv6 with L2 abstractions, but I am not 100% 
certain (It's been a while since I first saw it). I am also guessing the 
inset is what is recorded and the bigger video is what is shown on a 
remote machine. I could notice the interruption when there was no Access 
Point, but not during Handovers. Perhaps my eyes are not sharp enough 
:-) (Or you might say I am biased of course).

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 29 Apr 2006 02:27:30 +0200

Rajeev Koodli wrote:
> certain (It's been a while since I first saw it). I am also guessing
>  the inset is what is recorded and the bigger video is what is shown
>  on a remote machine.

So this demo shows FMIPv6/L2 abstractions (the main video) is somehow
less perfect than the perfect inset video which is the in-car recorded
video.  Meaning there's still work to do on FMIPv6 to improve it such
that no more interruptions, right?

> I could notice the interruption when there was no Access Point, but 
> not during Handovers. Perhaps my eyes are not sharp enough :-) (Or 
> you might say I am biased of course).

No, not eyes (not the video).  Check the sound while attaching to the
second AP, it's the classical tsss-tsss of lost UDP packets.  I'm not
saying biased.  I'm curious about the demo.

As a side note, I did a similar demo, filmed 3 years ago about handovers
GPRS-WiFi hotspot, same video filmed from car and there were indeed some
interruptions, but not during handover.  The app during inter-tech
handover was about perfect... But that's inter-technology handover...

Alex

---

From: Koshiro MITSUYA <[email-masked]>
Date: Sat, 29 Apr 2006 09:47:56 +0900

Hi Alexandru,

Quick reply.

Please refer to Appendix D., draft-koki-mobopts-l2- 
abstractions-03.txt about the video.
That's a demonstration for a link indication architecture, not FMIPv6  
itself.

However, we also have a similar demonstration (and video) with FMIPv6  
and some results.
Please wait for another mail to report them.

regards,
Koshiro