CARD protocol constants related / was: Re: CARD Review from Henrik Petander

Vijay Devarapalli wrote:

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


In the recent draft, we have the following constants specified for that 
purpose:
CARD_RETRANSMISSION_INTERVAL = 1 second
CARD_MAX_RETRIES = 3

As far as I remember, this is the mechanism and values you proposed,
including the upper limit. This mechanism replaced the previous mechanism,
which was based on the more dynamic approach using the rate-limiting flag.
Do you now propose to drop the MAX_RETRIES limitation?


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

The current draft specifies the following:
MN_AR_CARD_TIMEOUT = 1 sec
MN_AR_CARD_RETRIES = 5

>
> for (3), same as (2).

The current draft specifies the following:
AR_AR_CARD_TIMEOUT = 1 sec
AR_AR_CARD_RETRIES = 3

Referring to Henrik's feedback and addressed issue, the proposal was to
keep the MN-AR characteristics and to adjust the AR-AR characteristics 
as follows:
AR_AR_CARD_TIMEOUT: 300 ms
AR_AR_CARD_RETRIES: 2

There was no feedback yet.
Any comments?

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

If we modify the AR-AR characteristics to counteract the issue
Henrik referred to, this cannot be done.

>
> (4) is already clearly defined.

Right.

marco


>
> 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
>>>
>>>
>>>
>>>
>>>   
>>
>
>
>
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby