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

[Dhruv Dhody <[e-mail]>]

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
<[e-mail]> 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
> [e-mail] 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 ([e-mail])
>
> 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
   adjustment.

Thanks!
Dhruv