Re: (virtual) hum on CARD open issues

Marco Liebsch wrote:
> 

> I see your point. However, I don't see a reason why the flag as
> flow-control indicator
> should not work. Maybe there is also a benefit from implementation point
> of view on
> the MN. In case of having a flag, MN is notified when exceeding the
> request rate. Of course,
> AR has to maintain a per-MN state. Furthermore, rules have to be
> specified for MNs
> on how to behave when CARD Reply indicates exceeding rate. But from
> implementation point
> of view, this does not look very complicated on the MN side. However,
> having a
> "n-requests allowed per second"-rule on the MN, this needs to be
> controlled and
> implemented on the MN side, which looks like requiring a bit more effort
> 
> Alternative proposal was to indicate a maximum rate for a particular AR
> in the
> first CARD Reply. This keeps individual request rates flexible and avoids
> defining static numbers.

see my reply to Hemant.

>  From complexity and implementation point of view, I don't really
> understand why
> the proposed mechanism makes the protocol complex? I don't see
> any difference between having a check on the lifetime (==0x00000000?)
> and in case it's
> zero assume the capability to be static, and having a check on a
> specific flag (flag == 1?),
> indicating a static capability, hence, no lifetime field is present but
> "value" descriptor
> follows immediately.
> But if there are any further argumements and concerns, we can again
> think about it.

:) a new flag means extra fields in the data structure, 
extra code to check the flag, set the flag... you 
already have the lifetime field. and you would be anyway
checking the value of the lifetime field everytime you 
receive a capability parameter. I would generally avoid 
introducing additional flags.

and this comment

>but in the current form not many people are going to use 
>it. it might remain forever as an experimental, untouched,
>ignored, just another RFC.... that is something we should 
>avoid. I want a protocol that I can use. :)

was a specific reply to Ajoy's

>>Btw, in cellular standard I have seen even more complicated
>>procedure for saving 4 bits per frame

Vijay