 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
I agree with Vishwas. This is indeed per packet basis. Satyam > Date: Mon, 17 Aug 2009 12:04:54 -0700 > Subject: Re: DOWN state > From: vishwas.ietf at gmail.com > To: davari at broadcom.com > CC: satyamsinha at live.com; rtg-bfd at ietf.org > > 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 > > On Mon, Aug 17, 2009 at 11:50 AM, Shahram Davari<davari at broadcom.com> wrote: > > 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. > > > > > > Get back to school stuff for them and cashback for you. Try BingT now. |