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.
