Tuning BFD session times

Jeffrey Haas <jhaas@pfrc.org> Wed, 28 March 2018 18:49 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 240CD126CBF for <rtg-bfd@ietfa.amsl.com>; Wed, 28 Mar 2018 11:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id snBYmvW56G33 for <rtg-bfd@ietfa.amsl.com>; Wed, 28 Mar 2018 11:49:38 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org []) by ietfa.amsl.com (Postfix) with ESMTP id 112051201F2 for <rtg-bfd@ietf.org>; Wed, 28 Mar 2018 11:49:38 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id DC1521E402; Wed, 28 Mar 2018 14:49:59 -0400 (EDT)
Date: Wed, 28 Mar 2018 14:49:59 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: rtg-bfd@ietf.org
Subject: Tuning BFD session times
Message-ID: <20180328184959.GB25442@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/GXvLIf1o1zpC8QLCX-O6sNQ44G0>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2018 18:49:40 -0000

Working Group,

We had very active discussion (yay!) at the microphone as part of Mahesh's
presentation on BFD Performance Measurement.

I wanted to start this thread to discuss the greater underlying issues this
discussion raised.  In particular, active tuning of BFD session parameters.
Please note that opinions I state here are as an individual contributor.

BFD clients typically want the fastest, most stable detection interval that
is appropriate to their application.  That stability component is very
important since too aggressive of timers can result in unnecessary BFD
session instability which will impact the subscribing application.  Such
stability is a function of many things, scale of the system running BFD
being a major one.

In my opinion, applications should generally choose a detection interval
that is reasoanble for their application rather than try to dynamically
discover the lowest possible stable detection interval.  This is because a
number of unstable factors, such as CPU load, contention with other network
traffic and other things that are outside the general control of many
sytems may impact such scale.

That said, here's a few thoughts on active feedback mechanisms:
1. BFD is asymmetric.  This means a receiving BFD implementation must provide
   feedback to a sending implementation in order for it to understand
   perceived reliability.
2. Measurement infrastructure may negatively impact session scale.  Greg, I
   believe, made this point when discussing host processing issues vs. BFD
3. Detection interval calculations really need to take into account things
   that are greater than simple packet transmission times.  As an example,
   if your measurement is always taken during low system CPU or network
   activity, how high is your confidence about the interval?  What about
   scaling vs. number of total BFD sessions?

I have no strong conclusions here, just some cautionary thoughts.

What are yours?

-- Jeff