Subject: [mobile-ip] FMIPv6: Handover delay and Address reachability

From: Rajeev Koodli <[email-masked]>
Date: Fri, 27 Jun 2003 15:14:28 -0700

Hello folks,

we have had some good discussion. I would like to
bring out some points from the discussion. It is time
for the larger WG to progress the draft!

1. Relevance of HI and HAck.

Their intended purpose is to

- let NAR not invoke ND
- buffer incoming packets, and
- proxy NCoA

There was also a suggestion that HI and HAck can be used
to validate the forwarding for MN: i.e., PAR, with which NAR
should have a trust relationship, can validate the forwarding
entry at PAR. Perhaps this should be optional ?

There was a proposal (from Hesham Soliman) to make HI and HAck
optional. The reasoning, as far as I understand, is as follows.

Assuming that PAR has processed FBU, consider packet
arrivals at NAR. Performing address resolution, NAR creates
an ND cache entry in INCOMPLETE state and sends NS.
If the MN hears this (or a re-transmitted) NS, it responds
with a corresponding NA. If it does, NAR immediately
moves the ND entry to REACHABLE and starts forwarding
packets. Considering the variability in handover delay and
packet arrival times, this is less likely to happen.

In the more likely scenario, the MN simply sends an
unsolicited NA, which moves the cache entry state to STALE that
triggers neighbor reachability detection algorithm. However,
this proceeds in parallel with packet forwarding.

Here are my concerns with the above suggestion.

- It is not clear why NAR should buffer arriving packets
    any more than what ND would do for any arriving packets.
   A suggestion was to increase the size of the ND queue, for which
    RFC 2461 states:

    "While waiting for address resolution to complete, the sender MUST,
   for each neighbor, retain a small queue of packets waiting for
   address resolution to complete.  The queue MUST hold at least one
   packet, and MAY contain more.  However, the number of queued packets
   per neighbor SHOULD be limited to some small value.  When a queue
   overflows, the new arrival SHOULD replace the oldest entry.  Once
   address resolution completes, the node transmits any queued packets."

    Why should this generic queue be made larger because of handover?
Or,
     what indication NAR has to selectively make this queue larger for
handover
     packets ?

     What do others think ?

    Note that keeping the queue size as is, i.e., small could result in
packet
    loss, especially that of FBack since the oldest entry is replaced
first.

- It is implicit that FBack is received on the old link. Only then the
MN
    knows packets would be arriving at NAR. The MN cannot move after
    transmitting FBU because if FBU is lost, packets won't be arriving
at
    NAR. Hence, NAR will not have any ND cache entry, and according to
    RFC 2461, ignores the unsolicited NA that the MN sends.

     "When a valid Neighbor Advertisement is received (either solicited
or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, the advertisement SHOULD be silently discarded.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target."

- Even when NAR has an entry in INCOMPLETE state, moving the
    entry to STALE still invokes neighbor reachability detection
algorithm
    in parallel with packet forwarding. The additional message exchange
    over the air may not be desirable.

2) Relevance of FNA

The intended purpose of FNA is to

a) move an existing entry to REACHABLE state directly
b) to request creating one taking into consideration possible conflicts.

Sending unsolicited NA with O=1 accomplishes a) and should be
done when MN has received FBack and knows NCoA use is
acceptable. However, unsolicited NA won't create an entry
if NAR does not have one. If it does have one, there is additional
consideration of possible address conflict. So, the semantics of
FNA should address these considerations.

FNA is common for both predictive and reactive scenarios.
In the reactive scenario when MN sends FBU from the new link,
without FNA, router has to spend an additional round-trip performing
ND when packets packets arrive. It also serves to verify if NAR already
has an entry for some other node. In the predictive case, FNA announces
to NAR to deliver any buffered packets immediately.

The current format of FNA will be changed to be a Destination
Option so that FBU can be sent encapsulated (i.e, the Next Header
field in Destination Option points to IPv6) in a single
message. Such an encapsulation allows NAR to drop FBU in case
if it detects any conflicts for NCoA in its ND cache. It also helps
to acquire the radio channel only once.

I sense that this text related to FNA is acceptable for the next
version.
Let me know otherwise, suggesting alternative "text".

Thanks,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 27 Jun 2003 16:01:52 -0700

Rajeev,

>      what indication NAR has to selectively make this queue larger for

Several years ago (was it that long? :-) when we just started on the fast
handover work, I posted a couple of messages to the list describing the
consequences of having too big a queue on real time traffic. It results in
"ringing" where the router has to buffer packets while it is downloading
packets. The resulting perception for voice over IP is gaps in the signal.
The effect depends on the effective bandwidth of the wireless link. Note the
work "effective" here: a WLAN network with lots of MNs could result in an
effective wireless bandwidth that could cause impact.

So, I think we need to make an effort to minimize the size of the queue.

>     loss, especially that of FBack since the oldest entry is replaced

If the MN sends the FBU from the old link (predictive), the source address
will be the old CoA and, as you mention below, the MN must stay on the link
(if it can) until the FBack arrives, otherwise the optimization fails.

If the MN sends the FBU from the new link (reactive), then the source
address will be the new CoA and the FBack will be the very first packet
back, and there won't be a problem with queue overflow.

> Let me know otherwise, suggesting alternative "text".

I support this change because it minimizes the amount of signaling traffic
over the air prior to the MN getting its packets. This is an experimental
RFC, and I see no reason why we need to abide by the letter of RFC
2461/2462, as long as we're sure there's not interoperability conflicts.
Also, I think we need to keep the work modular, and not make it depend on
other proposals (such as optiDAD) which, though they may have value, are at
an earlier state of discussion. I suspect there will be a period of
consolidation and redesign after we've had some time to experiment and are
ready to go to Proposed Standard.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 27 Jun 2003 16:50:44 -0700

> So, I think we need to make an effort to minimize the size of the queue.

I dont think Rajeev is asking for a longer ND queue. 
infact he is saying it is typically short and if the 
mobile node doesnt show up on the new link soon enough 
buffered packets are dropped.

ND queue is typically per neighbor. the queue length is 
the same for every neighbor. RFC 2461 says it SHOULD be 
kept to a small value. Rajeev's point is that you either 
increase the ND queue for all neighbor cache entries 
(ignoring RFC 2461's recommendation) or keep them all 
small. it is not possible to selectively increase the 
queue length at the NAR only for the nodes undergoing 
fast handover without an indication from the PAR in the 
form of a Handover Initiate message.

Vijay