Subject: Re: [Ietf-behave] Time to add mapping/filtering entries

From: "Kaushik Biswas \(kbiswas\)" <[email-masked]>
Date: Tue, 5 Sep 2006 17:57:38 -0500 (CDT) (envelope-from [email-masked])

Agreed, one can recommend that rate-limit on per-user,etc shouldn't be
done by default and only by config, but my concern is more to do with
traffic-rate. Since from the initial discussion, looks like that was a
concern - that is if the traffic-rate or delay is such and such, then
certain NATs were ok and certain were not. This is where putting a
recommendation may not be right.

Thanks,
Kaushik

> -----Original Message-----
> From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] 
> Sent: Tuesday, September 05, 2006 3:18 PM
> To: Kaushik Biswas (kbiswas); Senthil Sivakumar (ssenthil); 
> 'Brian Stucker'; 'Pyda Srisuresh'; Cullen Jennings (fluffy)
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] Time to add mapping/filtering entries
> 
> > -----Original Message-----
> > From: Kaushik Biswas (kbiswas)
> > 
> > > I think we could make a generic requirement statement that "NATs 
> > > should not do any rate limiting unless explicitly 
> configured to do 
> > > so."
> > 
> > ...
> >
> > Now one shouldn't be putting in some statement which makes vendor B 
> > not complaint just because its CPU/memory-management scheme 
> may not be 
> > fast enough. IMO, it is good to highlight this issue, as 
> was found in 
> > Cullen's tests that certain NATs can handle traffic-rate 
> better than 
> > others, but we should stop short of a recommendation in this regard.
> 
> (Been silent for a bit but speaking up as I'm working with 
> precisely this issue right now)
> 
> I agree we shouldn't make a device non-compliant due to 
> having insufficient resources to handle a particular volume 
> of NAT bindings (CPU, memory, etc).
> But I agree with Senthil that we should recommend against 
> NATs rate-limiting new bindings that they could otherwise 
> handle, unless explicitly configured to do so.
> 
> (Incidentally, I'd count virus software and other automated 
> reconfigurations as "explicitly configured" for the sake of 
> this argument.)
> 
> -david
>