RE: DOWN state

["John Van Schouwen" <schouwen at nortel.com>]

Jitter is to be applied on a per-packet basis.

Here's a crude, simplified summary: Self-synchronization has to do with routers throughout a network synching up their periodic transmissions (such as with periodic hello packets) such that all routers send a burst of packets in unison, and then quiesce together for a time. It's an interesting phenomenon that is rooted in having all routers transmitting their periodic packets on near indentical periods. Though their timers may all be started randomly, over time--due to queuing latencies-- they eventually sychronize their timers with each other. (Apparently, this phenomenon can be seen with pendulum clocks hanging on the same wall; they eventually synchronize and swing in unison.) The bursty transmissions create havoc on routers' CPUs. So, there is a desire to avoid allowing routers self-synchronize. This can be accomplished by applying a large enough per-interval jitter on the periodic timers.  If you're really interested in the details, search on "self-synchronization" in Google or on the IETF Web site.

John van Schouwen
MG15K Bidirectional Forwarding Detection Team
Nortel Networks, Ottawa, Canada
email:   schouwen at nortel.com
Phone: (613) 763-8763  (external)
           ESN: 393-8763  (internal)

 

> -----Original Message-----
> From: Shahram Davari [mailto:davari at broadcom.com] 
> Sent: Monday, August 17, 2009 2:50 PM
> To: Vishwas Manral
> Cc: rtg-bfd at ietf.org
> Subject: RE: DOWN state
> 
> Hi Vishwas,
> 
> Thanks for your answer. But I just want to understand the 
> requirements. Is it required to calculate Jitter Per BFD 
> packet or it can be calculated once per BFD session and 
> applied to all packets of that session?
> 
> The base draft says the reason for applying Jitter is to 
> avoid synchronization mean. What does self synchronization mean here?
> 
> 
> Thanks,
> Shahram 
> 
> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf at gmail.com]
> Sent: Monday, August 17, 2009 11:44 AM
> To: Shahram Davari
> Cc: Satyam Sinha; rtg-bfd at ietf.org
> Subject: Re: DOWN state
> 
> Hi Shahram,
> 
> The more the randomness the more evenly distributed is the 
> packet send operation.
> 
> I understand your concern from the hardware perspective. It 
> need not however be the same level of pseudo-randomness as 
> required for security algorithms, which require specialized 
> hardware for the same.
> 
> Thanks,
> Vishwas
> 
> On Mon, Aug 17, 2009 at 11:32 AM, Shahram 
> Davari<davari at broadcom.com> wrote:
> > Hi Satayam,
> >
> > Are you saying that the Jitter is calculated and applied per BFD 
> > packet? or it is calculated once per session and applied to all 
> > packets of that session?
> > For example can one packet of a BFD session be jittered by 10% and 
> > another one by 20%?
> >
> > Thanks,
> > Shahram
> > ________________________________
> > From: Satyam Sinha [mailto:satyamsinha at live.com]
> > Sent: Friday, August 14, 2009 5:23 PM
> > To: Vishwas Manral; Shahram Davari
> > Cc: rtg-bfd at ietf.org
> > Subject: RE: DOWN state
> >
> > Hi Shahram,
> >
> > Comments inline....
> >
> >> Date: Fri, 14 Aug 2009 16:42:36 -0700
> >> Subject: Re: DOWN state
> >> From: vishwas.ietf at gmail.com
> >> To: davari at broadcom.com
> >> CC: rtg-bfd at ietf.org
> >>
> >> Hi Saharam,
> >>
> >> On Fri, Aug 14, 2009 at 3:49 PM, Shahram 
> Davari<davari at broadcom.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > The based draft sys that if BFD Control packet is not received 
> >> > during any Detection Interval then the local system will 
> go to Down 
> >> > state.
> >> > I have two questions:
> >> >
> >> > 1) When can the local system transition out of Down state? Is it 
> >> > after receiving the first BFD packet with State=DOWN or 
> INIT? or a 
> >> > number of such BFD packets are required? in other words 
> is there a 
> >> > Hysteresis?
> >> No hysteresis is required as such.
> >
> > Any hysteresis would actually be a violation of the 
> "Section 6.2 BFD 
> > state-machine".
> >
> > Down state means that the session is down (or has just been 
> created.)
> >    A session remains in Down state until the remote system indicates
> >    that it agrees that the session is down by sending a BFD Control
> >    packet with the State field set to anything other than Up.
> >
> >>
> >> > 2) Should the remote system apply  a sliding window for 
> Detection 
> >> > Time or fixed slotted windows that are not overlapped are 
> >> > acceptable?
> >> What does the window contain? (I understand you are trying to do 
> >> something similar to TCP). Are you using a mechanism like that for 
> >> echo packets?
> >
> > From a transmit perspective, if you take into account jitter, one 
> > should have the timers as sliding window based. One should schedule 
> > the next transmit at last-transmit-time + tx-timer 
> (jittered) instead 
> > of expected-last-transmit-time + tx-timer (jittered). The 
> variance in 
> > the jitter alongwith slotted window usage between two 
> transmits could 
> > cause the tx-time between two packets to be more than the tx-timer. 
> > When the multiplier=1, such a variance could make your 
> session go down.
> >
> > From a receive perspective you could do either. If you used slotted 
> > windows, you might see more than one packet in a slot but you are 
> > still guaranteed to see atleast one packet every slot.
> >
> > Regards,
> >
> > Satyam
> >
> > ________________________________
> > Get your vacation photos on your phone! Click here.
> 
> 
> 
>