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

[Dhruv Dhody <[e-mail]>]

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

On Wed, Aug 28, 2019 at 7:36 PM Black, David <[e-mail]> 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 <[e-mail]>
> > Sent: Wednesday, August 28, 2019 2:54 AM
> > To: Black, David
> > Cc: [e-mail]; [e-mail]; [e-mail] Discussion; draft-ietf-pce-
> > [e-mail]
> > 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
> > <[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