Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 1 Jul 2003 16:40:03 -0400

James,

The advantage of the R flag is that the MN does not have to know the rate
limit of the access router but can be alarmed when it approaches the rate
limit. The rate limit can depend on the bandwidth of the link, the
processing capacity of the access router, etc. The R flag does not require
predefined rate to be specified in the protocol. Now the rate limit is fully
open to the configuration. I think this flexibility is an advantage of the R
flag compared to the fixed inter-message interval method.

Dropping packets above the rate limit will be performed by the access
router. But if the MN does not know the rate limit, it will retransmit its
request. This retransmission will be just waste of rf bandwidth which we
like to save. So for the well-behaving MNs, it is good to give them an alarm
so that they don't do retransmission.

Eunsoo

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 01, 2003 2:29 PM
Subject: [Seamoby] [CARD Techical Issue] Rate limiting flag

> Last paragraph in in introduction to Section 4 says that the R flag is
used
> by the router to indicate to the MN to reduce sending rate of messages. As
> far as I know, this type of rate limiting is not done in any other IETF
> protocol (but I may be missing it).
>
> Typically, there are two ways that IETF protocols rate limit that I am
> familiar with:
>
>     - by specifying a constant intermessage time which clients are
required
> to abide by
>     - by having the server (router in this case) drop packets selectively
> when traffic gets too heavy
>
> The former works for well-behaved hosts, the latter reduces the impact of
> DoS attackes.
>
> Is there something about CARD that recommends this approach rather than a
> standard IETF protocol approach?
>
>             jak
>
>
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
>

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Tue, 1 Jul 2003 11:29:22 -0700

Last paragraph in in introduction to Section 4 says that the R flag is used
by the router to indicate to the MN to reduce sending rate of messages. As
far as I know, this type of rate limiting is not done in any other IETF
protocol (but I may be missing it).

    - by specifying a constant intermessage time which clients are required
to abide by
    - by having the server (router in this case) drop packets selectively
when traffic gets too heavy

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 1 Jul 2003 13:47:28 -0700

What about other nodes on the link? The rate limit is not simply for one
node, but for all. That's why protocols such as RFC 2461 or RFC 260 have
fixed default but configurable limits for the intermessage time. A rate
limit flag allows a host to hog up to the limit before the router starts
dropping.

So it needs two limitiing mechanisms, one on the host (the intermessage
time) and one on the router (selective dropping when the rate increases too
high). The latter doesn't involve the host.

            jak

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 2 Jul 2003 08:57:58 +0300 (EEST)

Hi James,

just a quick example of the use of flag bits: ECN-bits with TCP.

Jukka

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Jul 2003 08:32:30 -0700

> just a quick example of the use of flag bits: ECN-bits with TCP.

Ok, so it sounds as if there is a precedent. But I'm wondering if the case
here is the same. Wouldn't a host-based mechanism, in which the host is
required to limit the intermessage time, be simpler?

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 2 Jul 2003 12:04:14 -0400

James,

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.

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Jul 2003 15:06:04 -0700

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

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.

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.

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 3 Jul 2003 10:20:29 -0400

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

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

> 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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 3 Jul 2003 08:29:30 -0700

> wondered what would be the base in picking a certain number as the default

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

> limiting should be applied to AR-AR interaction as well. The R flag will

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

> Please let me ask a different question. What is the problem with the R
flag

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