Re: DOWN state

[Vishwas Manral <vishwas.ietf at gmail.com>]

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.