Re: [CARD Techical Issue] Rate limiting flag

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

Best to check what other protocols do. See RFC 2461 and RFC 2608 for
protocols that have a similar need.

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

OK, then keep the rate flag in, but be sure to mention why it is there:
messages can go over multihop links, rate flag helps with congestion
control. The difference is important. The default but configurable sending
rate helps with the load on the router, the flag helps with congestion
control (like the TCP ECN bits).

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

The problem I see, in addition to the distinction articulated above, is that
other protocols with a similar function don't work this way. So, this is an
item that is likely to catch the IESG's attention as a reason to return the
document to us. It is not a deep design or architectural issue. A flag could
be used for rate control as well as congestion control, it just isn't
typically so used in IETF protocols. We can argue about it for weeks (we've
already gone over a week), but it is something that is likely to delay the
progress of the draft IMHO.

If the flag is in and the IESG returns the document to Seamoby because of
it, you are going to get an email from me with "I told you so!" in large,
upper case letters. :-)

            jak