Subject: RE: issue 8

From: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
Date: Mon, 30 Sep 2002 21:50:09 +0530

Hello,

    I still don't quite understand how applying jitter (as currently defined
would help). Jitter, as per draft-17, is to be applied on a per speaker
basis, and not on a per peer basis.

    Given this, how does applying jitter on ConnectRetry timer help ?

Siva
([email-masked])

> -----Original Message-----
> From: Natale, Jonathan [mailto:[email-masked]]
> Sent: Monday, September 30, 2002 8:17 PM
> To: [email-masked]'; Natale, Jonathan
> Cc: [email-masked]
> Subject: RE: issue 8 
> 
> 
> Curtis,
> 
> So you are agreeing with the proposed change which is to add 
> ~= "jitter may
> be applied to the ConnectRetry".  I thought we already had 
> consensus on
> this.  Anyway, my email was merely to answer Sivananda's questions: Is
> adding a jitter to the ConnectRetry timer a standard 
> practice? -AND-  What
> benefit does this provide?
> 
> Also, I am not sure that I agree with your statement: "does not pose
> interoperability problems".  Bringing up all the peers at once would
> possible cause a network load spike.
> 
> I also find it interesting that it is recommend to add jitter 
> all the timers
> except 1--the only 1 that actually has jitter (in most of the 
> real world)!
> In my mind, this is the one that needs jitter the most.  
> Admittedly, I do
> not have sufficient empirical evidence to support this.  But 
> the one entity
> that does, seems to have conveyed the result in the form of 
> working code.
> 
> Jonathan
> :-) 
> 
> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]] 
> Sent: Monday, September 30, 2002 9:55 AM
> To: Natale, Jonathan
> Cc: [email-masked]
> Subject: Re: issue 8 
> 
> 
> Jonathan,
> 
> As far as the BGP spec is concerned it is fine to just say that jitter
> should be applied to all timers.  Whether a particular vendor does so
> for a particular timer does not pose interoperability problems, at
> worst is very minor deficiency in an implementation, and therefore is
> irrelevant to the discussion of what should be recommended in the
> protocol spec.
> 
> Curtis
> 
> 
> In message
> <[email-masked]
> ks.com>, "Natale, Jonathan" writes:
> > It seems to me that if you bring up all bgp peers at once it
> > may lead to load spikes on the network.  Cisco seems to wait
> > 27.5 +/- 2.5 seconds for IBGP, and 40 +/- 5 seconds for
> > EBGP--20 sec. from config time to the "open active, delay"
> > jittered delay assignment plus the jittered delay (5 to 10
> > sec. for IBGP, and 15 to 25 sec. for EBGP).  This would also
> > apply for "no neighbor x.x.x.x shutdown".  Their value of
> > ConnectRetry is 60sec.  though, not sure how this value is used
> > (based on above).  Maybe some Cisco folks can chime in on
> > this one???
> > 
> > I did not check Juniper.
> > 
> > Also, interestingly, they do not apply jitter to
> > the other timers (as far as I can tell), but I don't see
> > a problem with this.
> > 
> > Another timer that they use that is not mentioned in
> > the draft/rfc is the next hop resolution timer which is 30
> > seconds.  Although it would be nice to have this in the spec,
> > I will concede that it is out of scope and/or
> > implementation dependent.
> > 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[email-masked]] 
> > Sent: Thursday, September 26, 2002 12:34 PM
> > To: Yakov Rekhter
> > Cc: [email-masked]; Sivananda Ramnath - CTD, Chennai.
> > Subject: Re: issue 8 
> > 
> > 
> > The TCP connection establishment timer is 75 seconds (sysctl yield
> > "net.inet.tcp.keepinit: 75000" in BSD-oids).
> > 
> > The ConnectRetry determines when to make a second attempt after a
> > prior attempt to connect has failed.  It is to avoid a rapid
> > succession of retries on immediate failures (for example "Connection
> > refused" if the peer was in the middle of a reboot, Network
> > Unreachable if you can't get there from here, etc) but also 
> covers the
> > case where the TCP SYN goes off and is never heard from again.
> > 
> > Curtis
> > 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 30 Sep 2002 13:15:13 -0400

In message <[email-masked]>, "Sivanand
>     Given this, how does applying jitter on ConnectRetry timer help ?

Applying it on a per speaker basis means selecting a range on a per
speaker basis from which the random number is selected on a per timer
usage basis.

You can't possibly think that a BGP speaker selects a timer value with
jitter at boot up and uses the same value all the timer.  (I hope).
Jitter within some range is added for each use of a timer.

Curtis