Subject: BFD Performance Measurement

From: Ashesh Mishra <[email-masked]>
Date: Wed, 6 Dec 2017 13:52:47 +0000

Hi BFD experts,

We recently submitted a new individual contribution on BFD Performance Measurement. Please review the document and provide comments.

https://datatracker.ietf.org/doc/draft-am-bfd-performance/

This document proposes a mechanism to determine the smallest BFD transmit interval that can be supported on the link.  This is achieved by actively measuring the one-way delay for each BFD session and setting the BFD session intervals based on the measured delay. This allows the BFD session to adapt to the fastest rate feasible on the current active path.

The method described in this proposal is useful in networks where the network latency is high, or varies with time.  Trans-oceanic links and connectivity over geo-synchronous satellites are typical examples of links where the latency is high and the difference in latency on primary and backup paths can be significant. Another use-case is connectivity using satellites in mid-earth orbit (MEO) or low-earth orbit (LEO).  In these systems the one-way delay, while it is low (25msec to 150 msec), varies with time.  This variation, based on various factors, can be as high as 30 msec.  With mobile receivers, such as ships, the delay when using such connectivity can be non-trivial to predict.  This requires an automated method to determine the optimal BFD interval to allow fastest possible recovery in case of failure.

Thanks,
Ashesh Mishra
Mahesh Jethanandani

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 19 Dec 2017 12:24:11 -0500

Ashesh,

I'll take it as a given that there's an implied gripe about a lack of TLVs
for BFD and a push for BFDv2. :-)

The work in here seems reasonable, but does run up against the question I
always must ask: Is this actually useful/usable at high BFD rates?

I understand that a likely scenario (and not documented in the draft) is you
start with a sedate enough transmit interval so as to get your measurements.
But once you have them, I would expect that a poll would be initiated to
utilize faster timers.  Once we get to the fast timers, would the procedures
for handling the timestamps be reasonable to run at that rate?

-- Jeff

---

From: Ashesh Mishra <[email-masked]>
Date: Tue, 19 Dec 2017 12:30:10 -0500

It really depends on the use-case and the implementation. This measurement may be excessive if running at a 3.3ms or 10ms interval, but you don’t run these intervals on anything but the best and most deterministic of links. For links with higher or unpredictable latency, the typical intervals are at least 50msec (typically between 100msec and 500msec). At those rates, the overhead is not significant. 

At the same time, with more software implementations coming to the market, the overhead is smaller compared to the hardware implementations as there is no additional offload to a different engine. 

Ashesh

On Dec 19, 2017, at 12:24 PM, Jeffrey Haas <[email-masked]> wrote:

Ashesh,

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 19 Dec 2017 12:46:15 -0500

Ashesh,

> At the same time, with more software implementations coming to the market, the overhead is smaller compared to the hardware implementations as there is no additional offload to a different engine. 

Given that this may run against unknown software or hardware based
implementations, how do you foresee the procedures working to avoid swamping
a slow implementation?  For example, what's the impact of missing one or
more packets carrying this information within the Detection multiplier of
packets allowed to be dropped?

-- Jeff

---

From: Ashesh Mishra <[email-masked]>
Date: Tue, 19 Dec 2017 12:51:18 -0500

Same logic as authentication. Either both ends run it or neither end runs it. 

Additionally, dropped frames don’t impact the math as the exchange is just one frame forward and reverse. If any packet is lost, the  particular exchange disappears. This missing exchange should have no impact on the overall algorithm for determining the interval (outside the scope of the document as it’s an implementation detail at the receiver). 

Ashesh

On Dec 19, 2017, at 12:46 PM, Jeffrey Haas <[email-masked]> wrote:

Ashesh,

-- Jeff