Subject: Re: RSVP refresh interval

From: [email-masked]
Date: Wed, 29 Sep 1999 09:01:26 -0700

*> From [email-masked] Wed Sep 29 04:14:50 1999
  *> Date: Wed, 29 Sep 1999 11:28:30 +0100 (BST)
  *> From: Robert Stewart <[email-masked]>
  *> Reply-To: Robert Stewart <[email-masked]>
  *> Subject: RSVP refresh interval
  *> To: [email-masked]
  *> MIME-Version: 1.0
  *> Content-Type  *> :   *> TEXT/plain  *> ;   *> charset=us-ascii  *> 
  *> Content-MD5: FbpJoc2OlEc6DMM/Ys6BlA==
  *> X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc 
  *> Sender: [email-masked]
  *> Precedence: bulk
  *> Content-Length: 350
  *> X-Lines: 9
  *> 
  *> Hi all
  *> I am an inquisitive researcher who is interested in soft state signalling 
  *> systems. Could somebody inform me how the developers of the standards (RFC 2205) 
  *> decided on the 30 second refresh interval for RSVP. 
  *> ----------------------
  *> Robert Stewart ([email-masked])
  *> Electronic Engineering Department
  *> Queen Mary and Westfield College
  *> 
  *> 

Pretty much out of the air.  Well, 30 seconds is an old ARPANET/Internet
Canonical Timeout.  For example, the early Tops20 TCPs used to ping
all neighboring gateways every 30 seconds (until we discovered that
pinging gateways from hosts is a VERY BAD idea!). ;-)

30 seconds is at the upper range of "people response times", the
maximum that you expect a person to be willing to wait for the
robustness mechanism to kick in in those (expected to be rare)
instances when it was required.  It was chosen at the upper end to
minimize default signaling overhead.  There is not more rocket science
than that.  Note that 30 seconds is only a recommended default; a node
is free to use a different value.  We fully expected that with
experience vendors might adopt some other value, probably somewhat
smaller.

I am forwarding this to the rsvp mailing list, since it is a
protocol specification issue.

Bob Braden

an RSVP message was lost and the