Re: CARD Review from Henrik Petander

you are right. the names for the protocol constants are confusing.

basically we need to do the following

1. We need to rate-limit requests from the MN.
2. specify retransmission behavior for the MN.
3. specify retransmission behavior for the Current AR.
4. specify sending behavior for unsolicited CARD replies

for (1), we need a protocol constant to say that the MN is not allowed 
to send
more than a certain number of requests per second. if it sends more than 
that,
the current AR just drops the requests. There shouldnt be an upper limit on
the number of requests.

for (2), we need protocol constants. one to say when to retransmit and 
one to
say when to give up.

for (3), same as (2).

(2) and (3) could share the same protocol constants.

(4) is already clearly defined.

Vijay

Henrik Petander wrote:

>Hi Vijay and all,
>
>Vijay, thanks for the clarification.  CARD_MAX_RETRIES is 3 and
>MN_AR_CARD_RETRIES is 5, so MN can try to resend the same query for 5
>times, but can make new queries (for different L2 addresses) only 3 times.
>Did I understand this correctly?
>
>If yes, then this scheme is a little confusing to me and raises some
>questions: Why is the interval called CARD_RETRANSMISSION_INTERVAL, if it
>concerns new requests, which are not resends?
>
>Why is there a fixed ceiling on how many new CARD requests MN can send ?
>Shouldn't there at least be a wait period after which MN can set the
>counter to zero?
>
>Thanks,
>
>Henrik
>
>On Thu, 9 Oct 2003, Vijay Devarapalli wrote:
>
>  
>
>>hi Henrik,
>>
>>    
>>
>>>What is the purpose of CARD_RETRANSMISSION_INTERVAL and CARD_MAX_RETRIES?
>>>
>>>      
>>>
>>they are used in rate-limiting MN requests
>>
>>   the MN MUST send
>>   only one CARD Request per CARD_RETRANSMISSION_INTERVAL and not more
>>   than CARD_MAX_RETRIES. If the MN sends requests more frequently, the
>>   AR SHOULD drop the CARD requests and not process them.
>>
>>Vijay
>>
>>
>>
>>
>>    
>>