Re: [CARD Techical Issue] Rate limiting flag

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

----- Original Message ----- 
From: "Eunsoo Shim" <[email protected]>
To: "James Kempf" <[email protected]>; <[email protected]>
Sent: Tuesday, July 01, 2003 1:40 PM
Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag


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