Subject: RE: questions on INFORM draft

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 19 Aug 2002 11:53:43 -0400

Jeff:
 Section 7.1.1 states,
"The rate at which INFORM messages are generated must be rate-limited.
 A suggested default limit is 60 messages per minute." This does not
 imply that messages are lost, just that status is conveyed 60 times
 per second.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Monday, August 19, 2002 11:18 AM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> Subject: Re: questions on INFORM draft
> 
> 
> On Mon, Aug 19, 2002 at 11:11:53AM -0400, Abarbanel, Benjamin wrote:
> >  How, if TCP gaurantee delivary. You mean likely to be old or stale?
> 
> INFORM proposal, section 7.1.1
> 
> -- 
> Jeff Haas 
> NextHop Technologies
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 19 Aug 2002 12:00:26 -0400

>  imply that messages are lost, just that status is conveyed 60 times

Typically, rate limiting will imply loss of information when
"noisy" events happen.
Queues should not grow without bound.

-- 
Jeff Haas 
NextHop Technologies

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 19 Aug 2002 12:17:38 -0400

Clearly if you're generating events at a mean rate greater than 
one/second, then 60/minute rate-limiting will result in the loss of 
events (or delay approaching infinity if you have an infinite queue 
available in your router :-).

Our intent in the proposal is that implementors should generate 
events sparingly (at a mean rate much lower than one/second) and _if_ 
micro-events are deemed to be worthy of an INFORM they should be 
aggregated.

Furthermore as we discussed on the list about a month ago and as the 
current version of the draft explicitly states in 7.1.2, we 
specifically don't want INFORM to be part of BGP's control loop. 
This relates to rate limiting in that it implies loss or delay of an 
INFORM won't affect the operation of the protocol.  On the other 
hand, allowing INFORMs to be spewed arbitrarily fast would have the 
potential to delay important messages such as UPDATEs; a bad thing.

Regards,

--John

>  imply that messages are lost, just that status is conveyed 60 times
...