Re: CARD: handling of sequence numbers

Marco Liebsch wrote:
> 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.

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