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

From: David Black via Datatracker <[email-masked]>
Date: Tue, 27 Aug 2019 13:37:56 -0700

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
[email-masked] 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 ([email-masked])

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 28 Aug 2019 12:24:25 +0530

Hi David,

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

> strongly encouraged to propose alternative values and/or text to address

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

---

From: "Black, David" <[email-masked]>
Date: Wed, 28 Aug 2019 14:04:33 +0000

Hi Dhruv,

>    have settled out before bandwidth samples are taken for the next bandwidth

That's a good start - I'd like to see some suggested time values to help out an operator who doesn't understand this area and is just looking for guidance on something simple that is safe to do.   The default value of 5 minutes is definitely safe, whereas 1 minute seems to carry some risk, so how about:

    Due care is required by the operator if a Sample-Interval value significantly
    smaller than the 5 minute default is used, as small Sample-Interval values, e.g.,
    1 minute or less, could cause undesirable interactions with transport protocols.
    These undesirable interactions result from providing insufficient time for transport
    protocol reactions to a prior bandwidth adjustment to settle out before bandwidth
    samples are taken for the next bandwidth adjustment.

My goal for this text to encourage an operator who does not understand this area to just use 5 minutes, and spend brain-time on tinkering with more important things ...

Thanks, --David

> -----Original Message-----
> From: Dhruv Dhody <[email-masked]>
> Sent: Wednesday, August 28, 2019 2:54 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked] Discussion; draft-ietf-pce-
> [email-masked]
> Subject: Re: Tsvart last call review of draft-ietf-pce-stateful-pce-auto-
> bandwidth-10
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi David,
>

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 29 Aug 2019 10:44:30 +0530

Thanks David for the text, it is added in the working copy.