Re: CARD: handling of sequence numbers

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

Henrik Petander wrote:

>On Mon, 20 Oct 2003, Eunsoo Shim wrote:
>
>  
>
>>>>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?
>>>>        
>>>>
>>>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.
>>>
>>>      
>>>
>>If both time intervals are the same, does the AR need to distinguish a
>>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
>  
>