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 <noreply@xxxxxxxx> 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 > tsv-art@xxxxxxxx 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 (david.black@xxxxxxxx) > > 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
