Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FN A)

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Fri, 12 Aug 2005 08:35:45 -0500

> >> 
> > 
> > Why is that? Predictive mode vs. reactive mode differs in 
> when the MN 
> > is sending the FBU. All the information the MN needs for 
> > autoconfiguration can be obtained from the PrRtAdv - no?
> 
> Yes, MN could autoconfigure an address from PrRtAdv but it is 
> not worth doing so if it sends the FBU only after attaching 
> to NAR.  There's no point (no relevant gain in "speed") for 
> MN to autoconfigure an address from PrRtAdv as opposed to 
> autoconfigure an address from RS/RA on NAR.
> 

Why can't the FBU still be sent from the old link? What does assigned addressing have to do with it? Once the MN autoconfigures an IP address based on the info from PrRtAdv, can it not send an FBU to the PAR on the old link? 

Vidya

> (MN sends RS upon attachment to NAR and receives RA and then 
> sends FBU -  this takes 3 units of time in addition to about 
> 30units of  time for link-layer attachment.  If MN uses 
> PrRtAdv (instead of RS/RA)  it saves only 2 worthless units 
> of time.  The "units of time" are from  measurements of a 
> specific link-layer, the one that was presumably used  for 
> implementations.  More specifically: successful link-layer  
> attachment time is 90milliseconds, RTT on wireless is 
> 300microseconds.)
> 
> Alex
> 

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 16:31:52 +0200

Narayanan Vidya-CVN065 wrote:
>> Yes, MN could autoconfigure an address from PrRtAdv but it is not
>> worth doing so if it sends the FBU only after attaching to NAR.
>> There's no point (no relevant gain in "speed") for MN to
>> autoconfigure an address from PrRtAdv as opposed to autoconfigure
>> an address from RS/RA on NAR.
>> 
>  
> Why can't the FBU still be sent from the old link? What does assigned
>  addressing have to do with it? Once the MN autoconfigures an IP
> address based on the info from PrRtAdv, can it not send an FBU to the
> PAR on the old link?

The FBU _can_ be sent from the PAR link, to PAR.  But.

When PAR receives FBU, it sends HI, receives HAck and only then sends
back FBAck.  Assigned addressing is used in HAck/FBAck.  If "assigned
addressing" is removed from HAck/FBAck, then the entire semantics
change, namely there is no provision for replying back to MN that NAR
can't use that NCoA, so no reason to have a FBAck.  So there's no FBAck.
 So no reason to have FBU sent from MN on the old link.  There is no
reason why an FBU to be sent if there's no FBAck.

Second, as in previous post, not much is gained with sending FBU from
the previous link, as opposed to RS/RA/FBU on the new link.

Third, sending FBU prior a successful link-layer attachment is wishful
thinking.  The document acknowledges this in "Erroneous Movement" section.

So let me return the question: why would MN send FBU prior to attachment
to a new link?  What would it gain?  Is
RtSolPr/PrRtAdv/FBU/HI/HAck/FBAck any faster than RS/RA/FBU/FBAck?

Alex

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Aug 2005 16:59:55 +0200

> RtSolPr/PrRtAdv/FBU/HI/HAck/FBAck any faster than RS/RA/FBU/FBAck?

rfc2461 says:
    In all cases, Router Advertisements sent in response to a Router
    Solicitation MUST be delayed by a random time between 0 and
    MAX_RA_DELAY_TIME seconds. (If a single advertisement is sent in
    response to multiple solicitations, the delay is relative to the
    first solicitation.)  In addition, consecutive Router Advertisements
    sent to the all-nodes multicast address MUST be rate limited to no
    more than one advertisement every MIN_DELAY_BETWEEN_RAS seconds.

MAX_RA_DELAY_TIME is by default 0.5 seconds

u therefore have:
RS/RA implies a delay of a single RTT + rand(0ms,500ms)
FBU/FBACK implies a HI/HACK a 2*RTT delay, (or a single RTT if HI/HACK 
is removed as you suggest)

In other words these give you a significant delay. Do note that in the 
(predictive) case of obtaining your address while on PAR link you don't 
really care about the amount of time it takes since this is time while 
you still have connectivity. Doing so on NAR is different since you need 
the procedure to end in order to regain connectivity.

Cheers
Emil

---

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

> RS/RA implies a delay of a single RTT + rand(0ms,500ms)
                                          rand, right?  So could we be
optimistic, assume 0?  Or could we require that MAX_RA_DELAY_TIME be
shorter?  Instead of creating new messages?  Just like RAs for Mobile
IPv6 happen much faster than every 5 seconds that were previously
required for fixed hosts?

> the procedure to end in order to regain connectivity.

As I said previously, the amount of time the MN stays disconnected doing
link-layer stuff is one order of magnitude (if not two) larger than
exchanging messages with its first hop.  That says that quickening
something that is already fast is of little advantage.

Alex

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Aug 2005 17:50:52 +0200

Alexandru Petrescu wrote:
> optimistic, assume 0? 

Assume - I don't see how we could.

> Or could we require that MAX_RA_DELAY_TIME be
> shorter?  

This has many tradeoffs. I personally doubt there's any point in 
discussing them.

> something that is already fast is of little advantage.

This is quite a generic assumption. RTT between MN and AP on a 802.11 
connection, for example, is often  above 300ms. Link layer attachment on 
the other hand may go well below 100ms.

Cheers
Emil

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Aug 2005 17:51:55 +0200

Cheers
Emil

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Aug 2005 09:00:33 -0700

Yes, but DNA is trying to change this. The RAs will be sent immediately,
using a token bucket algorithm to control congestion. Check
draft-pentland-dna-protocol-01.txt

            jak

----- Original Message -----
From: "Emil Ivov" <[email-masked]>
To: "Alexandru Petrescu" <[email-masked]>
Cc: "Narayanan Vidya-CVN065" <[email-masked]>; "Junghoon Jee"
<[email-masked]>; <[email-masked]>; "James Kempf"
<[email-masked]>; "Koshiro MITSUYA" <[email-masked]>;
"Soliman, Hesham" <[email-masked]>
Sent: Friday, August 12, 2005 7:59 AM
Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FN
A)

---

From: "Ji Zhang" <[email-masked]>
Date: Fri, 12 Aug 2005 17:51:23 +0100

Hi Alex and all,

<snip>
> RtSolPr/PrRtAdv/FBU/HI/HAck/FBAck any faster than RS/RA/FBU/FBAck?

This may help to proactively perform the care-of address test to reduce the
return routability latency. Please see draft
http://www.ietf.org/internet-drafts/draft-zhang-mipshop-proactive-cot-00.txt
and comments are welcome.

Ji

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 19:41:06 +0200

Emil Ivov wrote:
>> Or could we require that MAX_RA_DELAY_TIME be shorter?
> 
> 
>> As I said previously, the amount of time the MN stays disconnected
>> doing link-layer stuff is one order of magnitude (if not two)
>> larger than exchanging messages with its first hop.  That says that
>> quickening something that is already fast is of little advantage.
> 
> 
>  connection, for example, is often  above 300ms.

Actually I've never seen RTT above (more than) 300ms.  I am curious to
learn about the conditions.  In my settings, pinging from laptop to AP
is 3ms and below... But I agree conditions may differ, in what
conditions were the tests performed?  Was that ftp/big packets?  Was
that with many Terminals on the link?  Was that 50meter distance from AP?

> Link layer attachment on the other hand may go well below 100ms.

Somehow agree, in my measurements 802.11b/laptop/pcmcia they're around
90ms if successful and 40ms if unsucessful.  Or that's how I interpret
time -p saying 0:0.09.  But this is not well below (much less than) 100ms.

Alex

---

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

> RtSolPr/PrRtAdv/FBU/HI/HAck/FBAck any faster than RS/RA/FBU/FBAck?

Actually the answer depends on when an MN is doing the FMIP. FMIPv6 assumes
that MN does RtSolPr/PrRtAdv/FBU/ at the handover anticipation while the MN
is still at the old link. This also implies that MN already know which
AP it is going
to attach to.

So the question is, is join/FNA faster than the Scan/RS/RA/FBU/FBAck? 
Also RS will involve the random delay even if RA hasn't with DNA.
Also handoff decision may involve much more than router discovery e.g. 802.21
Information Service.

I am sure the handoff latency depends on the L2 technology and it
support for scanning while attached to an AP/BS or simultaneous
attachment to more than
one AP/BS.

-Syam

---

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

Syam Madanapalli wrote:

>> So let me return the question: why would MN send FBU prior to
>> attachment to a new link?  What would it gain?  Is 
> Actually the answer depends on when an MN is doing the FMIP. FMIPv6
> assumes that MN does RtSolPr/PrRtAdv/FBU/ at the handover
> anticipation while the MN is still at the old link. This also implies
> that MN already know which AP it is going to attach to.
> 

I think "Scan" is an operation that may take longer than 5seconds
(802.11b/PCMCIA/laptop) and join would take 100ms, so obviously join/FNA
would be faster.

But the user mobility pattern/AP deployment are important factors on
seeing how often would the MN need to scan.  Maybe it needs to scan once
for 2-3 subsequent handovers.  Maybe it needs to scan before each handover.

And, if join/FNA is faster, and if it was very good to have set up all
data at NAR prior to MN attaching to it, then the question is: what
happens if MN decides _not_ to attach to the NAR (simply because user
moved physically back under PAR) and his decision came _after_ the
FBAck/FNA was sent.  Wouldn't at this point all data be wrong at NAR, at
PAR and at HA?  Wouldn't the MN's application loose many packets because
of this?

> Also handoff decision may involve much more than router discovery
> e.g. 802.21 Information Service.

At this point it is not very clear what 802.21 is.

I think it is good to try to extrapolate on advancements of various
technologies (link-layers, Internet Drafts, etc) but I also think we
should find a limit on that.  A tool for that is to rely extensively on
user needs, actual experimental results and so on.  Otherwise the risk
is to design stuff that works on paper and means nothing in practice.

> attachment to more than one AP/BS.

I agree with this.

Alex