Re: [Pce] Tsvart last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10

Dhruv Dhody <> Wed, 28 August 2019 06:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C6AB120867; Tue, 27 Aug 2019 23:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EI760VKThfxd; Tue, 27 Aug 2019 23:55:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0BB4120863; Tue, 27 Aug 2019 23:55:02 -0700 (PDT)
Received: by with SMTP id x4so3677925iog.13; Tue, 27 Aug 2019 23:55:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LaaogtHsxEhbjtVsHshzNjHGTmk/gIj/jSGOGn6s8I4=; b=RD37ScmddO5AEvNy83ZE/w9xIxTEn7NnbpUMHC56tRNN+WGuPL2C77Z6OS+SNnrVFH V6no+keZVfKEn1LXqGjh8eVXYLrsmuXHts9NqWtfl0dD+uqUrD5BWctvS1e2gdK9gyNk azwmMj3FbNbFdX5sZEKVCwaXSZYzafraMHZwkD+vGfhPgeohOnrgGhQzHD8mi/zsrPJL 3/lERPTg1JnyaXmYRphK+PUP8KuZzof49BniJ5+4iwdtUE43KUf4Hyw/Lb4Ak8hd6Rm4 tnb9jDqLUbVeSjGsg2DRovWilwbotgURkQviDwIcUeJX2dQomZ9VEFJSL7ZJI23gmhB+ hrMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LaaogtHsxEhbjtVsHshzNjHGTmk/gIj/jSGOGn6s8I4=; b=nMR6A/AmrKV96Bu07M1rcvMwhLYPzFnnQv8i9uSFp9GgP3c/pr+HJzcgWD6I5gg1ON 8MNVdTA2DzYMFirREVeHLi4nclHOcjWB3dxGYy8F6XHvsdgtevvHU17Paxyyvlw6dEhI MAnT0GFl9eV4wmmH0kXRvoQnqEGzY+szrrk4CxIhxq90LCf6oif/U+/xPdpkOO1NPQ7p 8XT5g5rOT894vPMNqYiScHnIosxd5kD/1ZORSoygDT3E6MfFYDghxW9VLK6ZO+HyKFOx De9wRLxC1sPZ1sAK/maXVyH4hQ5B4wYY7loe9MQ067nZyO1IrE49/U1bEWTI+27v6oDj tUSA==
X-Gm-Message-State: APjAAAVwAW8lJGfcNlKsYzpJEt+E77PAZXD5SozmP3jZ6PsypX+RXMSP mSvgvBmOYOaaAJEezCJpG1oXx6Z+7M+dWEgF10k=
X-Google-Smtp-Source: APXvYqy2xPdLU0dRTjK2WNiK+NOw3wp2qyD3ytt1d1OwTzQZVhGBA0wZRzsVGK/AaYlIqJi3K+13HnCQeZe3fqKtnLI=
X-Received: by 2002:a5d:9696:: with SMTP id m22mr407211ion.14.1566975302037; Tue, 27 Aug 2019 23:55:02 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Wed, 28 Aug 2019 12:24:25 +0530
Message-ID: <>
To: David Black <>
Cc:,, " Discussion" <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Pce] Tsvart last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Aug 2019 06:55:09 -0000

Hi David,

Thank you for your review and comments. Especially thankful to you for
a very clear description of the problem.

On Wed, Aug 28, 2019 at 2:07 AM David Black via Datatracker
<> wrote:
> Reviewer: David Black
> Review result: Ready with Issues
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> if you reply to or forward this review.
> -- Document --
>   PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with
>                               Stateful PCE
>               draft-ietf-pce-stateful-pce-auto-bandwidth-10
> Reviewer: David Black (
> This draft describes a stateful bandwidth auto-adjustment protocol for PCE
> (Path Computation Element) bandwidth adjustment of LSPs (Label Switched Paths).
> >From a Transport perspective, an important concern is how this bandwidth
> auto-adjustment interacts with transport protocol reaction to network
> conditions. These two phenomena should occur on vastly different timescales,
> so that any transport protocol reactions to a bandwidth adjustment have
> settled out before bandwidth samples are taken for the next bandwidth
> adjustment.  If the transport protocol reactions and bandwidth adjustments
> occur on similar timescales, undesirable interactions (e.g., oscillation)
> become possible.  Such undesirable interactions need to be avoided.
> The design center of this draft avoids these undesirable interactions, as
> the default sample interval of 5 minutes is much longer than the RTT-based
> (RTT = Round Trip Time) reaction times of transport protocols.  However,
> RTT is not the relevant metric here, e.g., as the initial BBR congestion
> control algorithm specified a probe of network conditions every 10 seconds.
> 5 minutes (more than an order of magnitude larger than 10 seconds) is still
> a reasonable sample interval, but in the extreme, the bandwidth auto-
> adjustment protocol in this draft is capable of sampling network bandwidth
> and reacting to it every second, which could cause undesirable interactions
> with transport protocols (e.g., that employ BBR with a 10 second probe
> interval).  The sample interval is of primary concern here, as the protocol
> adjusts bandwidth based on a single sample, namely the largest bandwidth
> observed in the adjustment interval.
> This reviewer expects that network operators would not configure such
> extreme parameters, and hence believes that the draft contains some unstated
> assumptions and/or recommendations about reasonable vs. unreasonable parameter
> settings. Those assumptions ought to be stated, e.g., sample interval
> SHOULD NOT be less than 1 minute.  There's nothing special about 1 minute -
> it's an easy-to-express amount of time that appears to suffice to avoid
> potential interactions with transport protocols - the draft authors are
> strongly encouraged to propose alternative values and/or text to address
> this concern.

How about adding something like this -

   Due care is required by the operator while setting a smaller Sample-Interval
   to avoid any undesirable interaction with the transport protocols (if any)
   to make sure that any transport protocol reactions to a bandwidth adjustment
   have settled out before bandwidth samples are taken for the next bandwidth