Subject: RE: [Mipshop] FNA in the current spec

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 18 Aug 2005 13:46:23 -0400

Rajeev,

 > > => But you can't set something to REACHABLE without confirming
 > > that it is in fact reachable. The FNA doesn't give you
 > > that confirmation, so it's actually wrong to set the state
 > > to REACHABLE based on the reception of the FNA. It's a bug
 > > in the spec...
 > > You seem to be defending this as an advantage, it's not, it's 
 > > a bug. You could just as well say that the NAR sets the state to 
 > > REACHABLE if it receives HI :) This would save sending the 
 > FNA, but it's 
 > > still wrong...
 > 
 > I don't see it as a bug, but an extension :-) And, it works, 
 > correctly!

=> Correctly? This contradicts the following:

 > Setting it to REACHABLE is not according to standard ND 
 > behavior. 

=> I really think you misunderstand the purpose of the REACHABLE
state. Setting it to reachable is wrong because it gives the 
AR the impression that the node is reachable, which is definitely
not known at that point. This breaks the entire meaning
of REACHABLE. If you're going to do that then why not set everyone
to REACHABLE. You basically want to avoid NUD. This has nothing to
do with FMIP, you're modifying ND for no reason.

   But 
 > doing so allows us to avoid additional signaling. 

=> Signalling ? you mean NUD? Where is the requirement
to avoid NUD stated/justified??

Hesham

And, I am 
 > also asking 
 > folks to provide some input on what their experience has been on 
 > forwarding packets when in STALE state.
 > 
 > So, let's wait for some additional input.
 > 
 > Thanks,
 > 
 > -Rajeev
 > 
 > 
 > 
 > > 
 > > Hesham
 > > 
 > > 
 > > ===========================================================
 > > 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

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 18 Aug 2005 11:02:43 -0700

> => Correctly? This contradicts the following:

Yes, it works in implementation. I am open to hear
other implementation input.

> not known at that point. This breaks the entire meaning

I agree that reachability is not confirmed, but you are forwarding
packets anyway (to be confirmed via implementation input) in STALE 
state. And, the AR will do address resolution in the reactive case. So, 
the only way to avoid NS - NA exchange is to set it to REACHABLE.

> do with FMIP, you're modifying ND for no reason.

As I said, I would like to hear other input before making any
decision.

> => Signalling ? you mean NUD? Where is the requirement

I mean active probing when in STALE state or when there is no
state at all (as in reactive handover).

-Rajeev

---

From: Brett Pentland <[email-masked]>
Date: Fri, 19 Aug 2005 15:13:57 +1000

>> state. Setting it to reachable is wrong because it gives the AR the 
>> impression that the node is reachable, which is definitely

If the NCE goes into the STALE state (and there's no upper layer
indications to push in into REACHABLE), then there will be an NS/NA
exchange, but that will take place off the critical path, so I don't
think it's worthwhile to change the meaning of STALE/REACHABLE just to
save this exchange.

Brett.

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 19 Aug 2005 11:33:42 -0700

> exchange, but that will take place off the critical path, so I don't

for predictive may be. (We have got some useful input from
an implementation. I am hoping to get some more). For reactive,
it is on critical path.

Anyway, the spec needs to say that a MN has to send an unsolicited NA.
What we call this and the associated semantics should take into account 
the implementation experience as we move towards PS.

Thanks,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Aug 2005 11:38:11 -0700

I don't think it can send an unsolicited NA while the address is in
OPTIMISTIC state on the MN. Otherwise, it might overwrite a duplicate NC
entry on the router.

        jak

---

From: Emil Ivov <[email-masked]>
Date: Sun, 21 Aug 2005 20:40:16 +0200

So here's some more: (sorry for the delay)

> The question was do host implementations send an unsolicited NA after
> attaching to a new link or not. I think they don't, but I wanted some
> input.

Ah! I was close wasn't I!

Anyway - the answer is no. No unsolicited NA is being sent by the 
(linux2.6.8.1) IPv6 stack when attaching to a new link.

Concerning the other NCE experiments:

1) Setting NAR's NCE for the MN to STALE upon reception of HI- gives the 
same behaviour as setting it to REACHABLE. In other words - no NS is
being sent by the NAR when packets, destined to the MN, start arriving 
and they are directly forwarded to NAR's link. The MN starts receiving 
them right after it attaches to PAR's link. This means that it misses a 
few and that no buffering is done since NAR believes that the MN is there.

2) Not setting NAR's NCE to anything and sending an unsolicited NA from 
the MN upon connection produces the following results. Packets (in our 
case) start arriving prior to MN attachment and trigger NDisc. An NS is 
being sent and in the mean time packets are being buffered by the IPv6 
stack while waiting for a reply to that NS. The MN then arrives and 
sends its unsolicited NA. The fact that it's unsolicited doesn't seem to 
make any difference and it seems to be accepted by the NAR as a reply to 
  its NS (btw, the NA almost always comes before a retransmission of the 
NS). This "releases" the buffered packets and the MN gets them all (or 
at least as much as the driver keeps). This is probably the solution 
that we tend to favor performance-wise.

3) Not setting NAR's NCE to anything and not sending an unsolicited NA 
and having NAR try to modify its own NC cache from userspace upon 
reception  of an FNA. Doesn't work cause (as I've pointed out in my 
previous mail) by the time the fmipv6-ar user space daemon tries to add 
an NCE (i.e. as soon as the FNA arrives) there is already NDisc going 
on, trigerred by the tunnelled packets and it seems impossible to 
shortcut/override it once it has started. In that case packets 
(bufferred or not) start flowing after the first NS has expired, a 
second one is sent and it gets its reply.

Of course all described problems and the above sequence of events are 
highly specific to our testbed. It (the testbed) is quite roughly a 
setup that looks more or less the same way as the RFC diagram on page 5. 
The MN connects to the ARs through 802.11a/b/g wireless lan. and the ARs 
are interconnected with a 100 MBit wired link.

Hope this'll be helpful. Let me know if you have any further questions.

Cheers
Emil

---

From: Koshiro MITSUYA <[email-masked]>
Date: Mon, 22 Aug 2005 15:15:30 +0900

Hello,

Sorry for my delayed reply.  Here is another input from "TARZAN"  
implementation which is based on KAME IPv6 stack.

The answer is also no.  No unsolicited NA is being sent by the KAME  
IPv6 (actually FreeBSD-5) stack.

Concerning the NCE with our TARZAN implementation, in predictive mode:
(1) MN sent FBU to PAR, and the PAR exchanged HI/Hack with NAR.  The  
PAR then started to forward packets to NCoA.
(2) When the forwarded packets arrived at the NAR, the NAR performed  
ND and made it INCOMPLETE.
(3) MN sent FNA right after it attached to NAR's link.
(4) When the NAR received the FNA, it changed the state from  
INCOMPLETE to STALE.  At the same time, NAR started to forward the  
packets.
(5) Simultaneously, NAR sent NS about the MN and MN replied NA.

So we could confirm that NAR forward packets in STALE state while  
simultaneously doing reachability confirmation (NS, NA).

regards,
Koshiro

On 2005/08/22, at 3:40, Emil Ivov wrote:

> 1) Setting NAR's NCE for the MN to STALE upon reception of HI-  
> gives the same behaviour as setting it to REACHABLE. In other words  
> - no NS is
> being sent by the NAR when packets, destined to the MN, start  
> arriving and they are directly forwarded to NAR's link. The MN  
> starts receiving them right after it attaches to PAR's link. This  
> means that it misses a few and that no buffering is done since NAR  
> believes that the MN is there.
>
> 2) Not setting NAR's NCE to anything and sending an unsolicited NA  
> from the MN upon connection produces the following results. Packets  
> (in our case) start arriving prior to MN attachment and trigger  
> NDisc. An NS is being sent and in the mean time packets are being  
> buffered by the IPv6 stack while waiting for a reply to that NS.  
> The MN then arrives and sends its unsolicited NA. The fact that  
> it's unsolicited doesn't seem to make any difference and it seems  
> to be accepted by the NAR as a reply to  its NS (btw, the NA almost  
> always comes before a retransmission of the NS). This "releases"  
> the buffered packets and the MN gets them all (or at least as much  
> as the driver keeps). This is probably the solution that we tend to  
> favor performance-wise.
>
> 3) Not setting NAR's NCE to anything and not sending an unsolicited  
> NA and having NAR try to modify its own NC cache from userspace  
> upon reception  of an FNA. Doesn't work cause (as I've pointed out  
> in my previous mail) by the time the fmipv6-ar user space daemon  
> tries to add an NCE (i.e. as soon as the FNA arrives) there is  
> already NDisc going on, trigerred by the tunnelled packets and it  
> seems impossible to shortcut/override it once it has started. In  
> that case packets (bufferred or not) start flowing after the first  
> NS has expired, a second one is sent and it gets its reply.
>
> Of course all described problems and the above sequence of events  
> are highly specific to our testbed. It (the testbed) is quite  
> roughly a setup that looks more or less the same way as the RFC  
> diagram on page 5. The MN connects to the ARs through 802.11a/b/g  
> wireless lan. and the ARs are interconnected with a 100 MBit wired  
> link.
>

---

From: Brett Pentland <[email-masked]>
Date: Mon, 22 Aug 2005 17:36:25 +1000

Koshiro MITSUYA wrote:
> (2) When the forwarded packets arrived at the NAR, the NAR performed  ND 
> and made it INCOMPLETE.
> (4) When the NAR received the FNA, it changed the state from  INCOMPLETE 
> to STALE.  At the same time, NAR started to forward the  packets.

This is interesting.  I'm curious about step 5.  From my reading of
RFC 2461 (section 7.3.3), the NCE for the MN on the NAR should go into
the DELAY state and the NS then go out DELAY_FIRST_PROBE_TIME seconds
later but there is no SHOULD/MUST type language in that bit of text and
section 7.3.2 describes it as an optimization.

 From RFC 2461, section 7.3.3:

    The first time a node sends a packet to a neighbor whose entry is
    STALE, the sender changes the state to DELAY and a sets a timer to
    expire in DELAY_FIRST_PROBE_TIME seconds.  If the entry is still in
    the DELAY state when the timer expires, the entry's state changes to
    PROBE.  If reachability confirmation is received, the entry's state
    changes to REACHABLE.

Brett.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Aug 2005 08:56:40 -0700

What happens if there's a duplicate address on the link?

            jak

----- Original Message ----- 
From: "Emil Ivov" <[email-masked]>
To: "Rajeev Koodli" <[email-masked]>
Cc: "Soliman, Hesham" <[email-masked]>; <[email-masked]>
Sent: Sunday, August 21, 2005 11:40 AM
Subject: Re: [Mipshop] FNA in the current spec

> being sent by the NAR when packets, destined to the MN, start arriving and 
> they are directly forwarded to NAR's link. The MN starts receiving them 
> right after it attaches to PAR's link. This means that it misses a few and 
> that no buffering is done since NAR believes that the MN is there.
>
> stack while waiting for a reply to that NS. The MN then arrives and sends 
> its unsolicited NA. The fact that it's unsolicited doesn't seem to make 
> any difference and it seems to be accepted by the NAR as a reply to its NS 
> (btw, the NA almost always comes before a retransmission of the NS). This 
> "releases" the buffered packets and the MN gets them all (or at least as 
> much as the driver keeps). This is probably the solution that we tend to 
> favor performance-wise.
>
> 3) Not setting NAR's NCE to anything and not sending an unsolicited NA and 
> having NAR try to modify its own NC cache from userspace upon reception 
> of an FNA. Doesn't work cause (as I've pointed out in my previous mail) by 
> the time the fmipv6-ar user space daemon tries to add an NCE (i.e. as soon 
> as the FNA arrives) there is already NDisc going on, trigerred by the 
> tunnelled packets and it seems impossible to shortcut/override it once it 
> has started. In that case packets (bufferred or not) start flowing after 
> the first NS has expired, a second one is sent and it gets its reply.
>
> highly specific to our testbed. It (the testbed) is quite roughly a setup 
> that looks more or less the same way as the RFC diagram on page 5. The MN 
> connects to the ARs through 802.11a/b/g wireless lan. and the ARs are 
> interconnected with a 100 MBit wired link.
>

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 22 Aug 2005 10:02:55 -0700

Hi Emil,

I have two questions/clarifications:

1. HI/Hack processing is also in the userland in your
    implmenetation? Assuming yes, then what you are
    suggesting is that there is sufficient time to
    set the ND state to REACHABLE when HI is processed?

2. Have you tried the reactive case, where FBU is sent
    from the NAR's link?

Thanks again,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 22 Aug 2005 10:09:17 -0700

Hi Koshiro,

thank you for sharing this input.

In step (4) below, have you tried setting the state
directly to REACHABLE? Apparently, the fmipv6.org implementation
does it but upon processing HI.

Regards,

-Rajeev

Koshiro MITSUYA wrote:

>> 1) Setting NAR's NCE for the MN to STALE upon reception of HI-  gives 
>> the same behaviour as setting it to REACHABLE. In other words  - no NS is
>> arriving and they are directly forwarded to NAR's link. The MN  starts 
>> receiving them right after it attaches to PAR's link. This  means that 
>> it misses a few and that no buffering is done since NAR  believes that 
>> the MN is there.
>>
>> buffered by the IPv6 stack while waiting for a reply to that NS.  The 
>> MN then arrives and sends its unsolicited NA. The fact that  it's 
>> unsolicited doesn't seem to make any difference and it seems  to be 
>> accepted by the NAR as a reply to  its NS (btw, the NA almost  always 
>> comes before a retransmission of the NS). This "releases"  the 
>> buffered packets and the MN gets them all (or at least as much  as the 
>> driver keeps). This is probably the solution that we tend to  favor 
>> performance-wise.
>>
>> NA and having NAR try to modify its own NC cache from userspace  upon 
>> previous mail) by the time the fmipv6-ar user space daemon  tries to 
>> add an NCE (i.e. as soon as the FNA arrives) there is  already NDisc 
>> going on, trigerred by the tunnelled packets and it  seems impossible 
>> to shortcut/override it once it has started. In  that case packets 
>> setup that looks more or less the same way as the RFC  diagram on page 
>> 5. The MN connects to the ARs through 802.11a/b/g  wireless lan. and 
>> the ARs are interconnected with a 100 MBit wired  link.
>>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 22 Aug 2005 20:09:11 +0200

> What happens if there's a duplicate address on the link?

I was actually giving input (as I thought was requested) from different 
scenarios with a protocol implementation. I was not proposing protocol 
modification or optimization. Not in this mail exchange at least. So if 
your question is along the same lines, i.e. what would happen in our 
testbed using the fmipv6.org implementation if duplicate addresses 
occur, then I'd say - I don't know, this didn't happen.

Emil

---

From: Emil Ivov <[email-masked]>
Date: Mon, 22 Aug 2005 20:09:39 +0200

Rajeev Koodli wrote:
>     implmenetation? 

Yes

> Assuming yes, then what you are
Meaning, before tunnelled packets start arriving?  Yes there is. 
Actually creating the tunnel on PAR seems to take considerably more than 
modifying/creating an NCE.

> 2. Have you tried the reactive case, where FBU is sent

We have, though not that extensively. That one works ok since the AR 
doesn't yet have a state for the MN upon reception of the FNA so there's 
no problem in setting it to reachable.

And there's sth else I'd like to note. This is a purely implementation 
issue though but I thought you might find it interesting. In my previous 
mail I noted that sending an NA right after getting on the new link is 
what we seem to prefer compared to simply putting the NCE to REACHABLE 
or STALE (same thing impl wise) because it allows for packet buffering.

Well this is not always true because some wireless cards/drivers seem to 
be sending the link attachment event notification to user space a lot 
later (several hundreds of miliseconds) than actually receiving the 
association response and after becoming operational on the new link. In 
these cases - simply adding a REACHABLE/STALE entry in NAR's ncache 
gives considerably better results as the packets that are not lost while 
waiting for the L2 trigger event are quite more (voip case) compared to 
what might have been save by buffering.

Once again, I am not trying to bring that up as a protocol issue, I do 
believe that this is an implementation problem that needs to be fixed. 
Just thought that it might be worth noting.

(We're still experimenting so input comes as we get it)

Cheers
Emil

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Aug 2005 11:15:09 -0700

I'm not sure I understand your response.

The current spec was supposed to handle duplicates. Are you saying it 
doesn't, or that you've not QA'ed your implementation to check how it 
handles them?

            jak

----- Original Message ----- 
From: "Emil Ivov" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>; "Rajeev Koodli" <[email-masked]>; 
"Soliman, Hesham" <[email-masked]>; <[email-masked]>
Sent: Monday, August 22, 2005 11:09 AM
Subject: Re: [Mipshop] FNA in the current spec

> testbed using the fmipv6.org implementation if duplicate addresses occur, 
> then I'd say - I don't know, this didn't happen.
>
> Emil
>
>>>any difference and it seems to be accepted by the NAR as a reply to its 
>>>NS (btw, the NA almost always comes before a retransmission of the NS). 
>>>This "releases" the buffered packets and the MN gets them all (or at 
>>>least as much as the driver keeps). This is probably the solution that we 
>>>tend to favor performance-wise.
>>>
>>>an NCE (i.e. as soon as the FNA arrives) there is already NDisc going on, 
>>>trigerred by the tunnelled packets and it seems impossible to 
>>>shortcut/override it once it has started. In that case packets (bufferred 
>>>or not) start flowing after the first NS has expired, a second one is 
>>>sent and it gets its reply.
>>>

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 22 Aug 2005 15:42:36 -0700

> modifying/creating an NCE.

This is best amortized with link black out (i.e., no interface is
available). Even though router discovery can be made quick (e.g., with 
DNA), the ability to send FBU from the previous link using Proxy Router
messages makes it possible to achieve nearly lossless handovers.

> no problem in setting it to reachable.

This is interesting because if there is no state (INC), then it is
okay. But, if there is state, then FNA is ignored in your 
implementation. But, it seems like there is a clear API to change
the state.

> what might have been save by buffering.

So, the protocol should not prohibit from setting the state to
REACHABLE.

> Just thought that it might be worth noting.

Thanks!

-Rajeev

---

From: Koshiro MITSUYA <[email-masked]>
Date: Tue, 23 Aug 2005 10:41:27 +0900

Hi Rajeev,

The answer is no.  There is no modification on the NDP stack in step  
(4).

regards,
Koshiro

On 2005/08/23, at 2:09, Rajeev Koodli wrote:

>> The answer is also no.  No unsolicited NA is being sent by the  
>> KAME  IPv6 (actually FreeBSD-5) stack.
>> (1) MN sent FBU to PAR, and the PAR exchanged HI/Hack with NAR.   
>> The  PAR then started to forward packets to NCoA.
>> (2) When the forwarded packets arrived at the NAR, the NAR  
>> performed  ND and made it INCOMPLETE.
>> INCOMPLETE to STALE.  At the same time, NAR started to forward  
>> the  packets.
>>> Anyway - the answer is no. No unsolicited NA is being sent by  
>>> the  (linux2.6.8.1) IPv6 stack when attaching to a new link.
>>>
>>> gives the same behaviour as setting it to REACHABLE. In other  
>>> words  - no NS is
>>> starts receiving them right after it attaches to PAR's link.  
>>> This  means that it misses a few and that no buffering is done  
>>> since NAR  believes that the MN is there.
>>>
>>> 2) Not setting NAR's NCE to anything and sending an unsolicited  
>>> NA  from the MN upon connection produces the following results.  
>>> Packets  (in our case) start arriving prior to MN attachment and  
>>> trigger  NDisc. An NS is being sent and in the mean time packets  
>>> are being  buffered by the IPv6 stack while waiting for a reply  
>>> to that NS.  The MN then arrives and sends its unsolicited NA.  
>>> The fact that  it's unsolicited doesn't seem to make any  
>>> difference and it seems  to be accepted by the NAR as a reply to   
>>> its NS (btw, the NA almost  always comes before a retransmission  
>>> of the NS). This "releases"  the buffered packets and the MN gets  
>>> them all (or at least as much  as the driver keeps). This is  
>>> probably the solution that we tend to  favor performance-wise.
>>>
>>> 3) Not setting NAR's NCE to anything and not sending an  
>>> unsolicited  NA and having NAR try to modify its own NC cache  
>>> from userspace  upon reception  of an FNA. Doesn't work cause (as  
>>> I've pointed out  in my previous mail) by the time the fmipv6-ar  
>>> user space daemon  tries to add an NCE (i.e. as soon as the FNA  
>>> arrives) there is  already NDisc going on, trigerred by the  
>>> tunnelled packets and it  seems impossible to shortcut/override  
>>> it once it has started. In  that case packets (bufferred or not)  
>>> start flowing after the first  NS has expired, a second one is  
>>> Of course all described problems and the above sequence of  
>>> events  are highly specific to our testbed. It (the testbed) is  
>>> quite  roughly a setup that looks more or less the same way as  
>>> the RFC  diagram on page 5. The MN connects to the ARs through  
>>> 802.11a/b/g  wireless lan. and the ARs are interconnected with a  
>>> 100 MBit wired  link.
>>>