Subject: [Seamoby] CARD: handling of sequence numbers

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

"...The handling of sequence numbers in MN and RA for resending is not
defined. Should MN increase the sequence number on resend? Should AR
identify a CARD request similar to an old one, except for the sequence
number, as a resend and set a new timer for AR-AR resending? How does
AR identify a "new" request from MN from resends of an old one?"

I agree that we need to be more specific here.
In my opinion, the MN should always increase the sequence number also
for resent messages. In case of a huge delay, a MN may resend a packet 
and receive 2 replies. Different sequence numbers allow the MN to
associate each of the 2 replies to a request. Otherwise we need
to specify how the MN should behave what to do when receiving 2
replies with the same sequence number...
To your last point: Is an AR really required to distinguish a
"resent" Request from a "new" one?

marco 

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

---

From: Henrik Petander <[email-masked]>
Date: Tue, 14 Oct 2003 05:43:39 +0300 (EEST)

Hi Marco,

> "resent" Request from a "new" one?

Yes, if AR-AR resending is implemented, since AR will set a new AR-AR
resend timer when it receives a "new" request from MN. It should not do
the same for resends from MN for which it already has a timer.

If MN increases the sequence number for each resend, then AR needs
to be able to differentiate the new and resent messages by other fields. I
don't think this is a problem, though, since AR can just compare the
L2-ids of the messages.

Henrik

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 15 Oct 2003 17:39:23 +0200

>the same for resends from MN for which it already has a timer.
That means an AR should refrain from creating a new timer in case it is 
a retransmit
(which is reasonable), but should create a new timer in case a MN sends 
two requests
directly after each other, right? The current spec allows the MN to send 
only one
request per CARD_RETRANSMISSION_INTERVAL, which is set to 1 second.
In case we keep 1 second also for the MN_AR_TIMEOUT, there should not be 
a conflict,
right? Otherwise, we could also let the MN "flag" a CARD REQUEST in case 
it is a retransmission.
But I guess this introcuced more complexity compared to the benefit.
What do you think?  

>don't think this is a problem, though, since AR can just compare the
In a MN_AR CARD Request there is not necessarily to be a L2_ID present.
But don't you think we get rid of this problem with the updated design 
of allowed
retransmissions, where, according to your recent proposal, the MN-AR 
timeout should
cover all possible retransmissions between ARs? Or, as described above,
we could have a flag set in MN-AR CARD_REQUEST  in case of a 
retransmit... (???)

What do you think?

marco

---

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

> But I guess this introcuced more complexity compared to the benefit.

Isn't the MN-AR request resend interval the same as the minimum interval
for new requests? So a flag may be the easiest way to allow AR to
distinguish new requests from resends.

Henrik

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 20 Oct 2003 11:03:51 -0400

> distinguish new requests from resends.
If both time intervals are the same, does the AR need to distinguish a
resent Request from a new Request for rate limiting?

Eunsoo

---

From: Henrik Petander <[email-masked]>
Date: Tue, 21 Oct 2003 04:15:15 +0300 (EEST)

> resent Request from a new Request for rate limiting?

If it is OK that the AR sets the AR-AR resend timer for both, then there
is no need to distinguish them. This is OK with me.

Henrik

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 22 Oct 2003 16:54:59 +0200

Now, I think the solution depends on how we agree on another issue,
which is related to protocol constants for the retransmissions.
Again, according to Henrik's proposal to decrease the AR-AR retransmission
interval and max. amount of retransmission on the AR-AR interface fit into
one interval for MN-AR retransmission, then we get rid of the need to
explicitely mark MN-AR retransmissions because ARs won't have a
AR-AR timer set anymore in case of a MN-AR retransmission, right?

The proposed values for retransmission timers were as follows:

MN_AR_CARD_TIMEOUT: keep 1 sec.
MN_AR_CARD_RETRIES: keep 5
AR_AR_CARD_TIMEOUT: 300 ms
AR_AR_CARD_RETRIES: 2

We also need to take the max. allowed MN-AR request rate into account, 
which is
in the recent draft set to 1/sec. Vijay proposed 2/sec, which would 
require to
adjust the values for retransmission above appropriately.

However, if we set MN-AR request rate to 1/second and the MN-AR timeout to
1 second, what's the differnce then between a retransmission and a new 
request?

So, what do you think?

marco

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 22 Oct 2003 16:30:51 -0400

My comments are inline.

> adjust the values for retransmission above appropriately.

Maybe my comment about it is quite late. Anyway I wonder again why it should
be 2 seconds instead of 1 second. Could Vijay explain a little bit? Even
though I have no base, 2 secounds sounds somewhat long.

> 1 second, what's the differnce then between a retransmission and a new

There is no difference in terms of rate limiting this case. So I don't think
we need a marker for retransmitted Requests in the current specification.

Eunsoo

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Oct 2003 13:34:57 -0700

> though I have no base, 2 secounds sounds somewhat long.

2/sec in Marco's text refers to 2 requests per second, which
means a mobile node could send CARD requests every 500 ms,
but still be assured that the current AR wont drop it.

currently the MN shouldnt send more than 1 request per second.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Oct 2003 13:48:17 -0700

> adjust the values for retransmission above appropriately.

we are mixing up things here. in retransmissions you send the
same request again. the rate limiting mechanism is for limiting
the total number of requests the MN can send in a second.

it shouldnt be a problem to have MN-AR retransmission timeout to
be 1 second and have an upper limit of 2 requests per second for
MN-AR CARD requests.

they are not related. I will give you an example. a mobile node
sends a request. it waits a second for reply. if there is no
reply, the mobile node assumes that either the request or the
reply was lost and retransmits the request.

in another case, the mobile node sends a request. within another
200 ms, something changes (like the MN discovering a new AP with
a stronger signal). the mobile node now needs to send out
another CARD request for the new AP. the time gap between the two
requests would be just 200 seconds. waiting for a second before
you can enquire about this new AP is too long. it doesnt matter
whether the mobile node got a response to its first request.

Vijay

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 23 Oct 2003 11:48:16 +0200

Vijay Devarapalli wrote:

>> We also need to take the max. allowed MN-AR request rate into 
>> account, which is

Right, but your example assumes the successful case for sending a quick
new request where the reply to the previous request has been received.
What if a reply does not appear for some reasons after 500ms
and a MN just sends a new request. Then we can run into the timer 
setting problem,
which has been indicated by Henrik, on the current AR again. Or we could 
just
allow the AR to "overwrite" the running timer with the new request in 
this case
and ignore the previous request and associated possibly outstanding 
signaling
messages between ARs.

What do you think?

marco

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 23 Oct 2003 11:21:54 -0700

Marco Liebsch wrote:
> and a MN just sends a new request. 

in my earlier mail, I said it doesnt matter if there was a
reply or not to the earlier request. this is *another*
request.

> Then we can run into the timer 
> setting problem,
> which has been indicated by Henrik, on the current AR again. 

no you dont.

> Or we could 

there is no overwriting timers. there is no one single
timer for all requests per mobile node.

the way to implement re-transmission is very simple. after
you send a request, you put the message in a queue. you
initialize a timer, store the timer and the request in a
new data structure and add this data structre to the
re-transmission queue. when a reply is received, both the
request and the timer are removed from the queue. if the
timer expires and no reply is received, the request is sent
again. the timer is reset.

if request2 was sent while request1 is still in the
retransmission queue, the timer on request1 is not reset.
another timer is created and a new element is added to the
re-transmission queue. got it?

Vijay