Subject: [Seamoby] CARD: Storing sequence numbers in ARs' CAR table?

From: Marco Liebsch <[email-masked]>
Date: Fri, 10 Oct 2003 18:37:00 +0200

"...Should the sequence number be stored in CAR table to enforce ordering
of CARD replies ?"

In my opinion, an AR needs to remember the sequence number
of a request only until the associated reply can be sent.
What could be the advantage of maintaining the sequence
number in an AR's CAR table for a longer time? Info flow
is from AR->MN, so it's the MN's responsibility to choose
sequence numbers appropriately for correlating replies
with requests and possibly to counteract replay attacks.
In case there is a positive offset in sequence numbers between
two consecutive Requests, this should not matter, or?

marco

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Henrik Petander <[email-masked]>
Date: Tue, 14 Oct 2003 06:18:19 +0300 (EEST)

Hi Marco,

> two consecutive Requests, this should not matter, or?

AR also receives piggybacked and other unsolicited AR-AR replies from
other ARs. For these to have ordering, AR should IMO store the sequence
number from the AR-AR CARD message header it receives. Then the sequence
number in CARD request and reply could be used just for matching the
messages.

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.

Henrik

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 14 Oct 2003 10:14:54 -0400

Henrik and Marco,

My comments are inline.

> > two consecutive Requests, this should not matter, or?
[eunsoo] I agree with Marco that any gap between sequence numbers of two
consecutive Requests is not a problem. The CARD protocol does not have to
guarantee the order of the received Requests.

> number from the AR-AR CARD message header it receives.

[eunsoo] Right. MN or AR should remember the sequence number of the latest
unsolicited message from any (other) AR so that it can figure out the newer
information.

Then the sequence
> number in CARD request and reply could be used just for matching the
[eunsoo] Right. I think we all agree to this.

> header is _probably_ needed for sequence number, if strict ordering is a
[eunsoo] There is already the sequence number field in the headers of CARD
Request and Reply. Do you suggest any other field?

Eunsoo

---

From: Henrik Petander <[email-masked]>
Date: Wed, 15 Oct 2003 05:01:48 +0300 (EEST)

> 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. It seems that a per-CAR sequence number /
timestamp is needed in AR-MN reply for ordering to work.

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.

Henrik

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 15 Oct 2003 11:24:39 -0400

Henrik,

My comments are inline.

> 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 /
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.

> 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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 15 Oct 2003 11:31:42 -0400

Please let me fix one typo.

> Unsolicited Reply would be relevant.

Should be
> Unsolicited Reply would be IRRELEVANT.

Thanks for your understanding.

Eunsoo

----- Original Message ----- 
From: "Eunsoo Shim" <[email-masked]>
To: "Henrik Petander" <[email-masked]>
Cc: "Marco Liebsch" <[email-masked]>; "Seamoby"
<[email-masked]>
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
> > > > header is _probably_ needed for sequence number, if strict ordering
is
> a

---

From: Henrik Petander <[email-masked]>
Date: Fri, 17 Oct 2003 10:44:48 +0300 (EEST)

On Wed, 15 Oct 2003, Eunsoo Shim wrote:
> most up-to-date information.
>
> What do you think?

This should work well enough in most cases.

Henrik