RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

[Fred Templin]

No worries; I also had a mistake in my earlier messages when I failed to

mention the active queue management for last-hop routers in front slow links

recommended by the RFC 3150 BCP. (I don't know if the recommendation

extends to the case of the slow link occurring somewhere in the *middle*

of the network, however.) Active queue management (i.e., RED) deals with

bursts much better than the de facto tail-drop, which would seem to fit well

with our current leaning toward the token bucket rate-limiting scheme.

 

Fred

[EMAIL PROTECTED]

 

[EMAIL PROTECTED] wrote:

Oops !! stupid mistake of mine :)

 

The number of packets from A to B will be limited by the thin link and thus

B won't have to send ICMP back at a higher rate.

 

Regards

Mukesh

-----Original Message-----
From: Gupta Mukesh (Nokia-NET/MtView)
Sent: Wednesday, January 07, 2004 4:19 PM
To: 'ext Fred Templin'
Cc: [EMAIL PROTECTED]
Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

Fred,

 

Rethinking about the following example of yours. Do we need to consider

the asymmetric paths between A and B ? I guess, the problem can be seen

with even symmetric path. Let say the network is like

 

A <--- 1gig ---> C <--- 56 kbps --> D <--- 1 gig ---> B

 

Now A starts sending some packets and B generates ICMPv6 error

messages. If B is using bandwidth-based function for limiting the rate,

it would calculate the percentage using 1 gig link's bandwidth and will

overload the thin link between C & D.

 

Am I missing something ?

 

Regards

Mukesh

-----Original Message-----
From: ext Fred Templin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 07, 2004 5:32 AM
To: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView)
Cc: [EMAIL PROTECTED]
Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

Margaret,

 

On further consideration, I think the bandwidth-based method might actually

be dangerous in some situations. Suppose there were asymmetric paths

between nodes A and B; the path A->B consisting of all 1Gbps links and

the path B->A consisting of at least one long, thin link (56Kb modem, 3GPP

wireless, etc.) Even if B is able to authenticate the source addresses in

packets it receives from A, if the bandwidth-based method is used based

on a percentage of the bandwith of B's outgoing 1Gbps interface the queue

on a router at the head of a long thin link on the path B->A will overflow. In

other words, B might cause harmful denial-of-service if it blindly uses a

bandwidth-based estimate, since it has no way of knowing whether long,

thin links will occur on the return path.

 

As to timer-based, I think Mukesh has already given a good reason as to

why it is suboptimal; I think an arguement could also be constructed that

shows it to cause interoperability problems in some cases. So, I find

myself in the rare position of agreeing with Pekka on this subject.

 

Fred

[EMAIL PROTECTED]