Subject: RE: questions on INFORM draft

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

Sorry that is 60 times per minute.

Ben

> -----Original Message-----
> From: Abarbanel, Benjamin 
> Sent: Monday, August 19, 2002 11:54 AM
> To: 'Jeffrey Haas'; Abarbanel, Benjamin
> Cc: [email-masked]
> Subject: RE: questions on INFORM draft
> 
> 
> 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: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 19 Aug 2002 12:51:24 -0400

The point was, how can we loss information if we sent the INFORM 
status message once a second? 

My point is that at worst the information will be 1 second old + time
to transmit across the wire. How can that be an issue?

Ben

> From: John G. Scudder [mailto:[email-masked]]
> Sent: Monday, August 19, 2002 12:47 PM
> To: Abarbanel, Benjamin
> Cc: Abarbanel, Benjamin; 'Jeffrey Haas'; [email-masked]
> At 12:44 PM -0400 8/19/02, Abarbanel, Benjamin wrote:
> >Can you site some examples where subsecond information is 
> needed to be sent
> >to a peer?
> 
> Nope.  I seem to have lost the point of this discussion.
> 
> Regards,
> 
> --John
>

---

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

> On Mon, Aug 19, 2002 at 12:44:05PM -0400, Abarbanel, Benjamin wrote:
> Who needs subsecond?  More than 60 in a minute is good enough.
> 
So why not aggregate the information before you sent the INFORM and
then dont send more than 1 per second. 

> As an example, say we are getting INFORMs of a bad aspath that
> has been repaired.  It is quite possible that we may need to
> do this for the majority of the routes we are sent from a given
> peer.  This would mean potentially one INFORM per route we get
> sent.
> 
Whats the point in sending 60 messages almost all within the same 
few seconds. Its just going to sit in the receive queue of the 
destination peer. 

Aggregation of all the routes' status into one message with time delay, 
1 message per second is a more efficient way to handle it.

I contend that the implementation of a given INFORM message must decide
what is a reasonable way to burst or not burst data to a given destination
peer.

Ben