Subject: [mobile-ip] Comment on Issue 56 (Optimizations in DHAD)

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 15 Jul 2002 19:32:18 -0700

Hi all,

Yesterday in the Mobile IP meeting, I made a comment on Issue 56, which 
I want to re-iterate on the list.

The Issue is regarding optimizations of DHAD responses from HAs. There 
are two optimizations that seem to be in conflict:

1. When the HA is higest priority on the list, it omits its own entry 
from the list. Hence, if there is no entry with the sending HA's 
address, there is an implied entry with highest priority.

2. When the reply message exceeds the MTU of the sending interface, the 
packet is truncated to fit within one packet.

The apparent conflict is the following: if #2 happens (the packet is 
truncated), it is possible that an entry for the sending HA would have 
been very low priority (or even not in the list, if possible), but is 
now truncated and doesn't show up in the list, so the MN assumes there's 
an entry with highest priority.

Optimization #1 is a good one, since it is likely that the sending HA 
will always want itself as the highest priority. So to lose this 
optimization just to prevent the conflict case (which is unlikely -- it 
doesn't seem HA lists will be excessively long very often) is a shame.

So the compromise I suggested is the following, which will preserve both 
optimizations:

1. When the sending HA is highest priority in the list, omit it from the 
list. This is the same as the current proposal.

2. Define the following variables:
   i = number of entries in home agent list which will fit within MTU of 
sending interface
   j = posistion of sending HA in list
   k = total length of HA list
Now, when the whole list will not fit into a single packet (i < k), we 
can truncate the packet as follows: if the sending HA appears within the 
MTU (j < i), or the sending HA is highest priority (j=0), simply 
truncate the list by sending HAs {1..i}. If the sending HA would be 
truncated off the end of the list (i < j < k), simply send the truncated 
list, but replace the last entry with the sending HA {1..i-1, j}.

In this way, there is no ambiguity: the sending HA will either always 
appear in the packet (if it's past the truncation point, it is sent as 
the last entry), or it does not appear and we know that it is highest 
priority.

-TJ

---

From: "Kevin Miles" <[email-masked]>
Date: Tue, 16 Jul 2002 13:40:32 +0100

T.J. Kniveton wrote:

> will always want itself as the highest priority.

Why? It will depend on Preference values.

I don't really care which solution is chosen, but IMHO this seems like a
disproportionate amount of effort to *possibly* save 16 bytes in a packet that
already carries an overhead of 56 bytes even before the HA address list is
inserted. If bandwidth is that scarce, perhaps we should consider reducing the
size of the Reserved field which currently occupies 10 bytes. (Only (half)
kidding:-)

Regards,
Kevin.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Jul 2002 14:47:55 +0300

TJ posted rules that prevent a collision of the optimizations. Kevin
complained about the amount of effort we spend on this small feature
and the already existing Reserved field. I'm more or less in agreement
with both of you...

My suggestion is that we remove 8 bytes from the Reserved field as we
don't need to align at 16 byte boundaries in IPv6 (only 8). And then
we apply TJ's rule. Are we done?

Jari

---

From: "Kevin Miles" <[email-masked]>
Date: Fri, 26 Jul 2002 16:11:24 +0100

> we apply TJ's rule. Are we done?
Sure.

Kevin.