Hi Mukesh,
One of the issues raised was about rate limiting methods
suggested by the draft. The draft suggests Timer-based,
Bandwidth-based and Token-bucket based methods for limiting
the rate of the ICMP messages.
After going through the discussion about this in the archive
and thinking about thi
Pekka,
Pekka Savola wrote:
On Tue, 6 Jan 2004, Fred Templin wrote:
Generally speaking, it seems appropriate to exclude implementation
alternatives only if they are known to cause operational issues.
[...]
Traceroute not working (without unnecessary delays) is a serious
operational issue
On Tue, 6 Jan 2004, Fred Templin wrote:
> Generally speaking, it seems appropriate to exclude implementation
> alternatives only if they are known to cause operational issues.
[...]
Traceroute not working (without unnecessary delays) is a serious
operational issue, IMHO.
--
Pekka Savola
Generally speaking, it seems appropriate to exclude implementation
alternatives only if they are known to cause operational issues. One
case of concern is that of a reflection attack in which an anonymous
attacker (A) using a spoofed source address (C) sends a stream of
malicious packets to a middl
If we decide to keep the Timer-based method, another problem
is to decide the value of T (not more than one icmp to a given
source every T milliseconds). 1 ms might be overwhelming for
a 64 kpbs link and 100 ms will be over-restricting for 10
gbps link.
What about we keep the Timer-based method,
On Tue, 6 Jan 2004, Fred Templin wrote:
> Asterisks already appear all the time using 'traceroute'. That is why
> three responses are solicited from each hop and the process proceeds
> to the next hop even if only one response is received. (Indeed, many of
> the traceroutes I have seen will "knock
Pekka,
Asterisks already appear all the time using 'traceroute'. That is why
three responses are solicited from each hop and the process proceeds
to the next hop even if only one response is received. (Indeed, many of
the traceroutes I have seen will "knock three times" repeatedly when a
non-resp
On Tue, 6 Jan 2004, Francis Dupont wrote:
>I have to disagree here. Even if a very small device was not a
>router, it would have to respond to traceroutes etc., even though with
>lower probability that multiple ones would be happening
>simultaneously. But still, if e.g. a "dumb" h
In your previous mail you wrote:
On Tue, 6 Jan 2004, Francis Dupont wrote:
> In your previous mail you wrote:
>
>I would like to hear from people who would like to keep the
>Timer-based and Bandwidth-based methods with logical reasons.
>
> => Even if Token-based
On Tue, 6 Jan 2004, Francis Dupont wrote:
> In your previous mail you wrote:
>
>I would like to hear from people who would like to keep the
>Timer-based and Bandwidth-based methods with logical reasons.
>
> => Even if Token-based is the best method it can be a bit expensive
> to imple
In your previous mail you wrote:
I would like to hear from people who would like to keep the
Timer-based and Bandwidth-based methods with logical reasons.
=> Even if Token-based is the best method it can be a bit expensive
to implement (code size and memory requirements) on very small d
11 matches
Mail list logo
