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
