Subject: RE: [mobile-ip] FMIPv6 Address confusion

From: Soliman Hesham <[email-masked]>
Date: Sat, 28 Jun 2003 03:13:58 -0400

> >  > From 7.2.5 again, for unsolicited NA, an existing
 > >  > entry in INCOMPLETE state is set to STALE. This implies
 > >  > the router would invoke NUD for reachability confirmation.
 > >
 > > => Ok so you agree that an entry is created, great.
 > >
 > 
 > Just to be clear: if there is an existing entry in INCOMPLETE
 > state, the router moves it to STALE. If there is no entry, for
 > instance because PAR has not processed FBU, unsolicited NA
 > does not create an entry.

=> Correct.

 > > Your assumption about NUD is incorrect AFAIK.
 > > Please read section 7.3.3. The router should continue
 > > forwarding packet to a STALE entry. If no confirmation
 > > appears, it will do NUD in parallel. So the traffic
 > > is not delayed by NUD.
 > >
 > 
 > This is a good point.
 > However, you would still have another round-trip
 > because of NUD, although that does not stop traffic.

=> Correct.

 > >  > Well, after the MN attaches, creating an entry at NAR saves
 > >  > a round-trip when packets arrive.
 > >
 > > => Now you want to optimise ND not handovers...
 > >
 > 
 > FMIP goal is to enable a MN to send packets as soon as
 > new link is available and to enable it to receive packets
 > as soon as NAR detects its presence. So, creating an entry
 > asap is important.

=> Yes, and you agreed above that a STALE entry is created
and that the MN will send traffic as soon as it joins 
the link (after NA in my text and after F-NA in the draft).

 > >  > This is not just an implementation issue. Many 
 > "standard" existing
 > >  > implementations keep the buffer to 1-2 packets.
 > >
 > > => The draft suggests updating the AR with
 > > a zillion things, but it can't suggest increasing
 > > the queue size? Changing the queue size breaks everything
 > > doesn't it?
 > >
 > 
 > FMIP does suggest to buffer packets, but Not by
 > expanding the ND queue.

=> I'd love to know the difference...more below

 > > => Please stop using this small queue reason. I'm
 > > sorry but it's rediculous that we can't suggest a
 > > larger queue in the router....Let's talk about
 > > real problems.
 > >
 > 
 > Why is this not a real problem ? You didn't answer
 > my question. Why should a generic ND queue be made
 > larger for _all_ incoming packets because there are
 > handovers ? Do you disagree that ND queues at routers
 > are small ? If not, how would you selectively increase the
 > ND queue for handovers ?  FMIP does not
 > require generic ND queue to be made larger, and I don't
 > see why that should change.

=> So you're saying that FMIP requires a buffer
in the AR (volatile memory I hope you'd agree).
Now, as an implementer, how do you decide on the 
size of that buffer? It's a memory management
problem. Same goes for NC queue. There is nothing
new here. You know, you don't have to have a static memory
allocated on a per host basis ;) That's a pretty 
inefficient use of memory. This is a pretty
simple design issue. That's why I don't think
it's worth the cycles.

I'll send you text for my suggestion because
your summary email misinterpreted several subtle,
yet important, points that I was making.

Hesham

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 30 Jun 2003 11:36:41 -0700

> problem. Same goes for NC queue. There is nothing

There are two issues here. Size of the buffer and what
causes the buffer, and hence its size is an issue, creation.

Size of the buffer for FMIP is not specified. There is text
for ND queue size in 2461.

Now, consider the operation of the AR as it receives a
packet for an address for which it has no ND cache entry.
The router puts the packet in ND queue, which SHOULD be
small (typically 1-2 packets), until the address is resolved.
It does not make sense to require that this queue per host
be _made larger_ (either through #define or via growing the
memory buffer (mbuf, skbuf,..)) for all hosts because some of
the arriving packets are due to handover.

Using HI, if a packets arrives for NCoA, looking up ND cache
indicates to the router not to invoke ND, and instead to buffer
the packet in a separate FMIP buffer.

> simple design issue. That's why I don't think

Static or dynamic allocation, I don't see why we need to change
the ND queue anyway. 2461 not only has text suggesting the
size of the queue, but also how packets should be dropped. I
would stay away from changing that.

-Rajeev