Re: CARD: handling of sequence numbers

Vijay Devarapalli wrote:

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


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


>
> Vijay
>