Subject: DOWN state

From: "Shahram Davari" <[email-masked]>
Date: Fri, 14 Aug 2009 15:49:35 -0700

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?

2) Should the remote system apply  a sliding window for Detection Time or fixed slotted windows that are not overlapped are acceptable?

Thanks,
Shahram

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 14 Aug 2009 16:42:36 -0700

Hi Saharam,

On Fri, Aug 14, 2009 at 3:49 PM, Shahram Davari<[email-masked]> 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.

> 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?

Thanks,
Vishwas

---

From: Satyam Sinha <[email-masked]>
Date: Fri, 14 Aug 2009 17:22:37 -0700

Hi Shahram,

Comments inline....

> Date: Fri, 14 Aug 2009 16:42:36 -0700
> Subject: Re: DOWN state
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> 
> Hi Saharam,
> 

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.> 

>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!
http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=0809TL-HM

---

From: Dave Katz <[email-masked]>
Date: Sat, 15 Aug 2009 16:47:20 -0600

On Aug 14, 2009, at 4:49 PM, Shahram Davari 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?

The state machine should be clear on this (first received packet.)

>
> 2) Should the remote system apply  a sliding window for Detection  
> Time or fixed slotted windows that are not overlapped are acceptable?

This is an implementation issue outside of the spec.  There is no  
interoperability issue with slow timers;  it just means that it takes  
a bit longer for the local system to realize that things have gone bad.

--Dave

---

From: Dave Katz <[email-masked]>
Date: Sat, 15 Aug 2009 16:52:39 -0600

On Aug 14, 2009, at 6:22 PM, Satyam Sinha wrote:

> 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.

This doesn't matter as long as the timers aren't severely late.  In  
most cases the jitter subtraction will more than make up for latencies  
in the timer system, and even if a packet is sent a little late, it  
doesn't matter, so long as *some* packet arrives within the detection  
time.

> When the multiplier=1, such a variance could make your session go  
> down.

Not unless it is severely late;  the spec explicitly caps the actual  
interval at 90% of the nominal value for just this reason.

>
> 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.

This is all very implementation-specific, and is identical in  
character to any hello-based protocol.  The only real difference is  
that in some cases you may run BFD with a much shorter timeout, so all  
of the system components have to be up to the task, however you do it.

--Dave

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 17 Aug 2009 11:32:24 -0700

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:[email-masked]]
Sent: Friday, August 14, 2009 5:23 PM
To: Vishwas Manral; Shahram Davari
Cc: [email-masked]
Subject: RE: DOWN state

Hi Shahram,

Comments inline....

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.

Regards,

Satyam

________________________________
Get your vacation photos on your phone! Click here.<http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=0809TL-HM>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 17 Aug 2009 11:43:35 -0700

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<[email-masked]> 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?
> 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.

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 17 Aug 2009 11:50:28 -0700

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:[email-masked]] 
Sent: Monday, August 17, 2009 11:44 AM
To: Shahram Davari
Cc: Satyam Sinha; [email-masked]
Subject: Re: DOWN state

Hi Shahram,

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 17 Aug 2009 12:04:54 -0700

Hi Shahram,

It would be best to apply it per packet. Self synchronization in this
case would send timers for all sessions expiring symultaneously and
thus the load on the system/ network traffic not being uniform but
having peaks and troughs.

Thanks,
Vishwas

---

From: "John Van Schouwen" <[email-masked]>
Date: Mon, 17 Aug 2009 15:14:03 -0400

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:   [email-masked]
Phone: (613) 763-8763  (external)
           ESN: 393-8763  (internal)

> From: Shahram Davari [mailto:[email-masked]] 
> Sent: Monday, August 17, 2009 2:50 PM
> To: Vishwas Manral
> Cc: [email-masked]
> 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 
> 
> 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
> 
> > 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?
> >> On Fri, Aug 14, 2009 at 3:49 PM, Shahram 
> Davari<[email-masked]>
> >> wrote:
> >> > Hi,
> >> >
> > Any hysteresis would actually be a violation of the 
> "Section 6.2 BFD 
> > state-machine".
> >
> > 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: Satyam Sinha <[email-masked]>
Date: Mon, 17 Aug 2009 12:16:59 -0700

I agree with Vishwas. This is indeed per packet basis.

Satyam

> Date: Mon, 17 Aug 2009 12:04:54 -0700
> Subject: Re: DOWN state
> CC: [email-masked]; [email-masked]
> 
> Hi Shahram,
> 

_________________________________________________________________
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1

---

From: Dave Katz <[email-masked]>
Date: Mon, 17 Aug 2009 15:42:45 -0600

I'll make this more clear in the spec, which I'm spinning at the moment.

Note that the new spec is going to make jitter mandatory rather than  
optional (MUST rather than SHOULD).  This is necessary in order for  
the congestion avoidance algorithm that's being added to work.  (The  
IESG required that a congestion avoidance algorithm be specified.)

--Dave

On Aug 17, 2009, at 1:16 PM, Satyam Sinha wrote:

> requirements. Is it required to calculate Jitter
> > > The base draft says the reason for applying Jitter is to avoid  
> synchronization mean. What does self synchronization mean here?
> > >
> > >
> > > Thanks,
> > > Shahram
> > >
> packet send
> > > On Mon, Aug 17, 2009 at 11:32 AM, Shahram Davari<[email-masked] 
> > wrote:
> > >> Hi Satayam,
> > >>
> > >> For example can one packet of a BFD session be jittered by 10%  
> and another
> > >> one by 20%?
> > >>
> > >> Thanks,
> > >> Shahram
> > >>> On Fri, Aug 14, 2009 at 3:49 PM, Shahram Davari<[email-masked] 
> >
> > >>> wrote:
> > >>> > Hi,
> > >>> >
> > >>> > The based draft sys that if BFD Control packet is not  
> received during
> > >>> > any
> > >>> > receiving the first BFD packet with State=DOWN or INIT? or a  
> number of
> > >>> > such
> > >> Any hysteresis would actually be a violation of the "Section  
> 6.2 BFD
> > >> state-machine".
> > >>
> > >>> > 2) Should the remote system apply  a sliding window for  
> Detection Time
> > >>> > or
> Get back to school stuff for them and cashback for you. Try BingT now.