Re: WGLC for draft-ietf-bfd-large-packets

Jeffrey Haas <jhaas@pfrc.org> Fri, 13 September 2019 12:10 UTC

Return-Path: <jhaas@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 700AD120091 for <rtg-bfd@ietfa.amsl.com>; Fri, 13 Sep 2019 05:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 soQnDhJa5wq0 for <rtg-bfd@ietfa.amsl.com>; Fri, 13 Sep 2019 05:10:05 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C95B812008A for <rtg-bfd@ietf.org>; Fri, 13 Sep 2019 05:10:05 -0700 (PDT)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 3DB871E2F3; Fri, 13 Sep 2019 08:12:49 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: WGLC for draft-ietf-bfd-large-packets
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <4858942C-0B22-40EE-867E-23F24BA54B34@cisco.com>
Date: Fri, 13 Sep 2019 08:10:04 -0400
Cc: Reshad Rahman <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <14F6F67F-1421-4E04-B0AF-50FCCD96468C@pfrc.org>
References: <9ECC2E5C-E87E-4859-9DA8-E8E9403DF759@cisco.com> <C44550AC-F6E0-4351-9958-CB9144C9F23A@cisco.com> <4858942C-0B22-40EE-867E-23F24BA54B34@cisco.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/nlutfM3xEa3uyUC6opcgDSvrBHY>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 13 Sep 2019 12:10:07 -0000

Carlos,


> On Sep 12, 2019, at 10:56 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
> 
> Thanks for the reminder, Reshad. I support publication of this document, short and useful.
> 
> I only have one comment in regards to:
> 
>    It is also worthy of note that even if an implementation can function
>    with larger transport PDUs, that additional packet size may have
>    impact on BFD scaling.  Such systems may support a lower transmission
>    interval (bfd.DesiredMinTxInterval) when operating in large packet
>    mode.  This interval may depend on the size of the transport PDU.
> 
> Instead of (or in addition to) a lower transmission interval, why not add flexibility to not *have* to send large packets every packet, and instead send every n paks or so?

Such a thing could be done.  A form of this sort of thing for "probing" was discussed in a prior draft I did with Xiao Min, but that was for Echo mode.

But since this in BFD async mode, the timers are likely chosen for the worst case.  So, if we have the usual Detect Multiplier of 3 and we can support sending a large packet every (e.g.) 25ms, and our implementation would normally send smaller packets every 10ms, we'd need to negotiate for some range between 10 and 25 knowing that the occasional large packet may itself perturb timing enough it might be counted as loss.

So, such a thing could be done by an implementation, but timing is messy.  If you want something a bit more occasional, I suggest a reasonable set of timers in async mode and more clever procedures in Echo mode, if you support that.

-- Jeff