Re: BFD Performance Measurement

Jeffrey Haas <jhaas@pfrc.org> Tue, 19 December 2017 17:20 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6AB124C27; Tue, 19 Dec 2017 09:20:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFK59xJgyf2l; Tue, 19 Dec 2017 09:20:08 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6C912D7F4; Tue, 19 Dec 2017 09:20:08 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 34DEE1E35A; Tue, 19 Dec 2017 12:24:12 -0500 (EST)
Date: Tue, 19 Dec 2017 12:24:11 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Ashesh Mishra <mishra.ashesh@outlook.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Reshad Rahman <rrahman@cisco.com>, "jhaas@juniper.net" <jhaas@juniper.net>, "draft-am-bfd-performance@ietf.org" <draft-am-bfd-performance@ietf.org>
Subject: Re: BFD Performance Measurement
Message-ID: <20171219172411.GL8708@pfrc.org>
References: <645E4B77-3D56-41D4-9EFA-0FFF6AFF941E@outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <645E4B77-3D56-41D4-9EFA-0FFF6AFF941E@outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/kQj3E71pI9fxZdCks5DOh5cfB2o>
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: Tue, 19 Dec 2017 17:20:10 -0000

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

On Wed, Dec 06, 2017 at 01:52:47PM +0000, Ashesh Mishra wrote:
> 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