Subject: RE: issue 8

From: "Natale, Jonathan" <[email-masked]>
Date: Mon, 30 Sep 2002 10:47:26 -0400

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 
> 
> 
> In message <[email-masked]>, Yakov Rekhter
> writes
> :
> > forwarding...
> > ------- Forwarded Message
> > 
> > Date:    Thu, 26 Sep 2002 16:58:19 +0530
> > From:    "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
> > To:      Yakov Rekhter <[email-masked]>
> > Subject: FW: issue 8
> > 
> > Hello,
> > 
> >     My mail does not seem to have made it to the list. Could you please
> > forward it ?
> > 
> > Thanks,
> > Siva
> > ([email-masked])
> > 
> > - -----Original Message-----
> > From: Sivananda Ramnath - CTD, Chennai. 
> > Sent: Thursday, September 26, 2002 3:21 PM
> > To: [email-masked]
> > Subject: RE: issue 8
> > 
> > 
> > Hello,
> > 
> >     The ConnectRetry timer is should have a value that is 'sufficiently
> > large to allow TCP initialization. Application of jitter can reduce the
> this
> > value (by up to 25%). A configuration which the ConnectRetry timer has
> been
> > pegged at a value close to TCP connection time may cause a connection to
> be
> > terminated as a result of this jitter. Is this a cause for concern ? 
> > 
> >     The default value suggested for ConnectRetry (120 seconds) is
> > sufficiently large that event with a jitter of 0.75, it will be greater
> than
> TCP'c connection establishment timer.
> > 
> >     Is adding a jitter to the ConnectRetry timer a standard practice ?
> What
> > benefit does this provide ?
> > 
> > Sivanand
> > ([email-masked])
> 
> 
> 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 12:20:01 -0400

In message <[email-masked]
> benefit does this provide?

Yes.  We agree.  Jitter should be applied to all timers.

End of discussion I hope.  Please save the discussion of who actually
implements jitter on which timer for later.

Curtis