Re: DOWN state

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

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