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

From: [email-masked]
Date: Wed, 7 Jan 2004 18:26:44 -0600

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-masked]
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-masked]]
Sent: Wednesday, January 07, 2004 5:32 AM
To: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView)
Cc: [email-masked]
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
 <mailto:[email-masked]> [email-masked]

---

From: Fred Templin <[email-masked]>
Date: Wed, 7 Jan 2004 21:05:25 -0800 (PST)

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-masked]

[email-masked] wrote:
Oops !! stupid mistake of mine :)

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

Fred,

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

Margaret,

 
Fred
[email-masked]