Subject: RE: Section 2.4, item (f) of draft-ietf-ipngwg-icmp-v3-04.txt

From: [email-masked]
Date: Thu, 5 Aug 2004 22:57:19 -0500

Alex,

Thanks.. I will update the text in the next rev.

Regards
Mukesh

> -----Original Message-----
> From: ext Alex Conta [mailto:[email-masked]]
> Sent: Thursday, August 05, 2004 8:55 PM
> To: Gupta Mukesh (Nokia-NET/MtView)
> Cc: [email-masked]
> Subject: Re: Section 2.4, item (f) of draft-ietf-ipngwg-icmp-v3-04.txt
> 
> 
> Mukesh,
> 
> A first sentence like:
> 
> "The rate-limiting parameters SHOULD be configurable per node,
> if the node has similar speed/bandwidth interfaces, and/or per 
> interface, if the node has disimilar speed/bandwidth interfaces".
> 
> or
> 
> "The rate-limiting parameters SHOULD be configurable per node,
> if the node has similar interfaces, and/or per interface, if the node 
> has disimilar speed/bandwidth interfaces".
> 
> would be more explicit/descriptive.
> 
> The rest is fine.
> 
> Thanks,
> Alex
> 
> 
> [email-masked] wrote:
> > Alex,
> > 
> > Thanks for pointing this out.  What do you think about the following
> > as the replacement text?
> > 
> > =============
> >         The rate-limiting parameters SHOULD be configurable.  In the
> >         case of a token-bucket implementation, the best 
> defaults depend
> >         on the computational power of the device and the 
> speed/bandwidth 
> >         of the interfaces that it has (e.g., a high-end 
> router vs. an 
> >         embedded host, a 10G ethernet vs. a T1 interface).  
> For example, 
> >         in a small/mid -sized device with limited bandwidth 
> interfaces, 
> >         the possible defaults could be B=10, N=10/s.
> > ==============
> > 
> > Regards
> > Mukesh
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>ext Alex Conta
> >>Sent: Thursday, August 05, 2004 11:17 AM
> >>To: IPv6
> >>Subject: Section 2.4, item (f) of draft-ietf-ipngwg-icmp-v3-04.txt
> >>
> >>
> >>The last paragraph of Section 2.4, item (f) of 
> >>draft-ietf-ipngwg-icmp-v3-04.txt is pointing to ICMP rate limiting 
> >>configurability on a per node basis.
> >>
> >>ICMP Rate-limiting configurability makes sense also on a per 
> >>interface 
> >>basis.
> >>
> >>In a case of a router having different speed/bandwidth 
> >>interfaces, for 
> >>example IPv6 interfaces on fast links, as well as  slower 
> links, the 
> >>adequate ICMP rate-limiting parameters on a 1G or 10G 
> >>Ethernet, could be 
> >>quite different from a T1, or T3 link.
> >>
> >>Regards,
> >>Alex
> >>
> > 
> > 
> > 
> 
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked]
Date: Sat, 14 Aug 2004 20:46:38 -0500

Alex,

After all the discussion about this, do you still think that 
we should have per interface configuration for the token bucket
parameters?  I agree with Pekka that appropriate parameters
chosen per node should be good enough.

Regards
Mukesh

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Lowell Gilbert
> Sent: Monday, August 09, 2004 12:57 PM
> To: [email-masked]
> Alex Conta <[email-masked]> writes:
> 
> > Pekka Savola wrote:
> > > On Thu, 5 Aug 2004, Alex Conta wrote:
> > >
> > > I'm slightly concerned whether we have two implementations of
> > > interface-specific rate-limiting parameters, required for Draft
> > > Standard.  Do you know of any?
> > >
> > 
> > Are there any implementations were ICMP rate limiting is implemented
> > separately from other protocol packets traffic management (traffic
> > shaping)?
> 
> Sure, but I'm not sure that's important.
> 
> > If an IP implementation has support for traffic management, 
> the packet
> > schedulers (traffic shaping) associated with interfaces, handle ICMP
> > rate limiting per interface (in terms of both configuring and rate
> > limiting) similarly to other protocol packets traffic shaping per
> > interface.
> 
> Several systems have something like this, and then *also* have a
> separate mechanism for rate-limiting ICMP.  Often, that separate
> mechanism on applies to *outgoing* ICMP replies.
> 
> The language in question is already more verbose than does any good:
> the "and/or" negates any requirements that are intended by the
> distinction between having interfaces at similar speeds or not.  I
> think the requirement would be the same if it just said the parameters
> "should be configurable per node and/or per interface," with perhaps a
> *suggestion* recommending per-interface configuration, particularly on
> systems that are capable of supporting different interface types or
> speeds.  [This is not quite the same as what I would actually have
> recommended the document say to begin with; I'm only trying to comment
> on the language at the moment.]
> 
> Be well.
>