Re: BFD Performance Measurement
Jeffrey Haas <jhaas@pfrc.org> Tue, 19 December 2017 17:42 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 64FD412D94F; Tue, 19 Dec 2017 09:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh8Kf7Rpq2I4; Tue, 19 Dec 2017 09:42:11 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7C24E12D82E; Tue, 19 Dec 2017 09:42:11 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 6DE0C1E35A; Tue, 19 Dec 2017 12:46:15 -0500 (EST)
Date: Tue, 19 Dec 2017 12:46:15 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Ashesh Mishra <mishra.ashesh@gmail.com>
Cc: Ashesh Mishra <mishra.ashesh@outlook.com>, "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: <20171219174615.GM8708@pfrc.org>
References: <645E4B77-3D56-41D4-9EFA-0FFF6AFF941E@outlook.com> <20171219172411.GL8708@pfrc.org> <938A3102-0D82-4753-9958-4ED6F95C211E@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <938A3102-0D82-4753-9958-4ED6F95C211E@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/RR0f8NSM7d1qIcqoRDhO71yKFAo>
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:42:12 -0000
Ashesh, On Tue, Dec 19, 2017 at 12:30:10PM -0500, Ashesh Mishra wrote: > 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. 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
- BFD Performance Measurement Ashesh Mishra
- Re: BFD Performance Measurement Jeffrey Haas
- Re: BFD Performance Measurement Ashesh Mishra
- Re: BFD Performance Measurement Jeffrey Haas
- Re: BFD Performance Measurement Ashesh Mishra