Re: Re: CARD: Storing sequence numbers in ARs' CAR table?

Please let me fix one typo.

> As mentioned in the above. just copying the original sequence number may
not
> work because the original sequence numbers for Solicited Reply and
> Unsolicited Reply would be relevant.

Should be
> Unsolicited Reply would be IRRELEVANT.

Thanks for your understanding.

Eunsoo

----- Original Message ----- 
From: "Eunsoo Shim" <[email protected]>
To: "Henrik Petander" <[email protected]>
Cc: "Marco Liebsch" <[email protected]>; "Seamoby"
<[email protected]>
Sent: Wednesday, October 15, 2003 11:24 AM
Subject: Re: [Seamoby] Re: CARD: Storing sequence numbers in ARs' CAR table?


> Henrik,
>
> My comments are inline.
>
> > > > There is a similar problem is in the MN-AR protocol, with the
ordering
> of
> > > > solicited and unsolicited replies. A new field in the MN-AR CARD
> message
> > > > header is _probably_ needed for sequence number, if strict ordering
is
> a
> > > > requirement.
> > > >
> > > [eunsoo] There is already the sequence number field in the headers of
> CARD
> > > Request and Reply. Do you suggest any other field?
> >
> > Actually the problem in MN was more complex than I had thought: MN can
get
> > unsolicited CARD replies from multiple ARs and the information in ARs
> > about CARs is not synchronized.
>
> In most cases, a MN will have a single current AR and therefore it will
> receive CAR info only from the current AR. But in multi-homing cases, a MN
> can have multiple "current ARs", in which case, your point is right.
>
> > It seems that a per-CAR sequence number /
> > timestamp is needed in AR-MN reply for ordering to work.
> >
> This problem occurs because there can be multiple information distribution
> channels and scenarios. For example, one attribute value can be updated
> between two ARs using Request/Reply while another attribute value can be
> updated via the Unsolicited Reply.To enforce strictive synchornization or
> ordering of information, we would need timestamp for each attribute
> including the IP address and MAC address. This seems creating lots
overhead.
>
> > A potential solution is to include the original sequence number from the
> > AR-AR CARD reply message header (not reply option) in some field for
each
> > CAR, e.g. in the capability container suboption, in the MN-AR CARD
reply.
> > Provided that the CAR increases the sequence number for every AR-AR CARD
> > message it sends, this should work. The sequence number handling might
> > need to work with wrap around, though.
> >
>
> As mentioned in the above. just copying the original sequence number may
not
> work because the original sequence numbers for Solicited Reply and
> Unsolicited Reply would be relevant. Again, every Reply should have a
> timestamp(or sequence number) of the (Reply) sender and it should be
copied
> for each attribute value separately for strict ordering.
>
> I'd like to suggest a very simple approach instead of the strict
information
> synchronization or ordering.
> How about letting the MN use the following simple policy?
> 1) First, it takes Unsolicited Reply only from the default router (one of
> the multiple current ARs in the case of multihoming).
> 2) Second, it gives higher priority on the more recent information if it
is
> from the same sender (not the original source) --- In this case, the order
> is determined by the sequence number for Unsolicited Replies. If the MN
> receives Unsolicited Reply and Solicited Reply from the default router, it
> takes more recently received information.
> 3) Third, if the MN sent inquiry (Request) to multiple ARs, it takes the
> most recently received information (Reply).
>
> Certainly this approach opens a (little) chance that the MN may NOT get
the
> most up-to-date information. However, since we don't make sure the ARs
> synchronize their information in hard real-time, such a chance exists
> anyway. So inserting timestamp for every attribute value may not be
> justified by the gain compared to its cost.
>
> What do you think?
>
> Eunsoo
>
>
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby
>