Re: [CARD Techical Issue] Rate limiting flag

> > As said earlier, the bit makes the protocol flexible without major
> > additional complexity.
> > The value of flexibility is worth adding the one-bit flag, I think.
> > Also I guess the MNs would be need CARD information near handoff in most
> > cases.
> > That is, the CARD message traffic would be bursty to individual MN.
> Setting
> > a large inter-message time may not be desirable. Also allowing a too
short
> > inter-message time is not desirable, either. So the inter-message time
> > should be configurable. Then the MN should be informed about the vale
> which
> > could be different at different ARs. This brings additional complexity,
> > which the R flag can make unnecessary.
> > So I think there are significant advantages with the R flag.
> >
>
> I'm not arguing whether the inter-message time should be configurable,
just
> that a default should be included and that it should be configurable.
>
Well, we could recommend a default value that is configurable. But we
wondered what would be the base in picking a certain number as the default
value.

> The problem here is that protocols which operate on the local link, like
RFC
> 2461, typically have explicit intermessage times, whereas end to end
> protocols such as TCP (with ECN) do have explicit rate control. This
> protocol is more like the former.
>
Well, even though we are more concerned about MN-AR interaction, the rate
limiting should be applied to AR-AR interaction as well. The R flag will
work for both cases.

> I don't see that a rate flag makes the protocol any more or less flexible
> than having an explicit intermessage time enforced by the host, if the
> intermessage time is configurable. In either case, the protocol depends on
> the host to enforce the rate control.

I am repeating my self. If the inter-message interval is configurable, the
MN should be informed about it. To do this, the AR should send a message to
each MN, probably by periodic broadcast/multicast, or add additional fields
to the CARD reply. Again more rf bandwidth usage in addition to more
processing! The R flag removes this need. Isn't the R flag more flexible and
simpler?

Please let me ask a different question. What is the problem with the R flag
you can see?

Eunsoo