Thanks David for the text, it is added in the working copy. On Wed, Aug 28, 2019 at 7:36 PM Black, David <[email protected]> wrote: > > Hi Dhruv, > > Thanks for the quick response and suggested text: > > > 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. > > 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 protected]> > > Sent: Wednesday, August 28, 2019 2:54 AM > > To: Black, David > > Cc: [email protected]; [email protected]; [email protected] Discussion; > > draft-ietf-pce- > > [email protected] > > Subject: Re: Tsvart last call review of draft-ietf-pce-stateful-pce-auto- > > bandwidth-10 > > > > > > [EXTERNAL EMAIL] > > > > 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 > > <[email protected]> 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 > > > [email protected] 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 protected]) > > > > > > 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
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
