Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-auto-bandwidth-11: (with DISCUSS and COMMENT)

Dhruv Dhody <dhruv.ietf@gmail.com> Wed, 25 September 2019 08:27 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A79120122; Wed, 25 Sep 2019 01:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtuG9kZSJsE2; Wed, 25 Sep 2019 01:27:24 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3FC12011B; Wed, 25 Sep 2019 01:27:24 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id r26so11549153ioh.8; Wed, 25 Sep 2019 01:27:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rjYzGnExckWZIQdkXwfRNmmdf4SM/+aPi2jkgL4QAmU=; b=uWnRCp5DvTLVEX4JOr5xaQRBLCwrmonsgndl2c+01yO5cbvJvKQmKeHcCQi7e/fB2W xkRhpO0aiqYv3gKOBZQP2AiR3158t3gKB10Jwoaij6lOBeIlNY2trivS4IJDmZ32NjYA vsgMtBQ+lNj3KEcR17hsgwfSHQ6fJIxnRG8fElVzva6HcES7fYUZd2vpdRLHYKlu5ys1 MWVPDWv/zyCKhJzgBKthg2CYR1aPlJ1B8AgneA3102uE4rZMdESGQKOxEDpMFxwDOS7C c/iYUJoOnoz3P5yVagCH16cGsphkfpuTumwtFA/nNb7DizacJ7Gnv7//w9vi0J2HVLYN mxoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rjYzGnExckWZIQdkXwfRNmmdf4SM/+aPi2jkgL4QAmU=; b=BHiSUUpvZLoU6u4n2AZjy47HPBslFORrjH7c0Ls/gUNgqYTxy3wlrArKfPZi5haj9R G3w6LWheMxgmjQTat99VO7oD5saZCkK4Luk/F0es3vvhjdVX4AYNMirqFCe6ERGwccXX OTGdAQtdpSfkaa0rPKLFSgvh1tA1LUaXyyJQfndZ1p4uLjd74KSRJVryWy8052aJLPez pplao2S6kS37kSk7ZXIeoJrezw2JQsXxqQJ6W25dhvBYXNFDNuibTOxjh5CAotJWIWqk YJaEZp0ojqKwV1m1i3578I1DWN8gI/bY+SwKEodCuMsBVSaVTwkXTB2HcLmi3WeGgvKP EPdg==
X-Gm-Message-State: APjAAAVC1pmYvGQGTAgFRK85wBSfKq63KTvA6aVsoD4Bjt1x7cALTJL/ qouV3jEnVjNPWrRWkmRFh8Grc6b+VKxXZDAEoOM=
X-Google-Smtp-Source: APXvYqwg1yGBxZZ3bmgGLD5bVi5CuDAVE7tOp5T9bo6CkkF198yvy7Hm4MavtYviRYP6FYXqKXLP0E9qbJpOd3w3HP8=
X-Received: by 2002:a5e:d502:: with SMTP id e2mr6144486iom.279.1569400043776; Wed, 25 Sep 2019 01:27:23 -0700 (PDT)
MIME-Version: 1.0
References: <156874887441.17499.7855633347557404477.idtracker@ietfa.amsl.com> <CAB75xn5MUrTS43f5boMo4Kq7dfCo+YmLu1Qh_Qf-XN9hXLKsww@mail.gmail.com> <20190919202036.GA48975@kduck.mit.edu>
In-Reply-To: <20190919202036.GA48975@kduck.mit.edu>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Wed, 25 Sep 2019 13:56:46 +0530
Message-ID: <CAB75xn69TNsthD=KpmLFzekZ7PjOnGaj5G_RvpqucKk06XGAOw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, pce-chairs <pce-chairs@ietf.org>, pce@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/8f9hGu3y8OKGuGkKD22ttgedR3k>
Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-auto-bandwidth-11: (with DISCUSS and COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 08:27:28 -0000

Hi Ben,

Thanks for the discussion.

Snipping to open points..

> > >
> > > As a general note, I'm not sure the phrase "calculated bandwidth to be
> > > adjusted" is a great fit for how it's currently being used.
> > > Specifically, the "calculation" in question seems to just be taking the
> > > maximum of a sliding window of per-timeslice average bandwidth values,
> > > and this seems like a sufficiently small amount of computation that I'd
> > > be comfortable describing it as a "measurement", for "measured bandwidth
> > > as input to path calculation".  That is, this doesn't seem like it comes
> > > close to the amount of computation involved in actually computing paths,
> > > so I keep misreading what information is being sent where.
> > >
> >
> > In an earlier version there was a feature where the PCC could report
> > the measured value at each sample interval (it moved to another
> > document). IMHO for the clarity in the WG, it is still better to
> > differentiate between the raw measured value (telemetry) and the value
> > that is currently reported which is marked as "calculated".
>
> Ah, in that context it makes more sense to do it this way.  Perhaps an
> informative reference to the other document/usage and note about the
> terminology would help, though?
>

I have added - "Another approach would be to send the measured values
itself to the PCE, which is considered out of scope for this
document.". In terminology I highlighted 'measured' and 'calculated'
in the existing terms.

> > > Section 1
> > >
> > >    Over time, based on the varying traffic pattern, an LSP established
> > >    with a certain bandwidth may require to adjust the bandwidth reserved
> > >    in the network dynamically.  The head-end Label Switch Router (LSR)
> > >    monitors the actual bandwidth demand of the established LSP and
> > >    periodically computes new bandwidth.  The head-end LSR adjusts the
> > >    bandwidth reservation of the LSP based on the computed bandwidth
> > >    automatically.  This feature is commonly referred to as Auto-
> > >    Bandwidth.  The Auto-Bandwidth feature is described in detail in
> > >    Section 4 of this document.
> > >
> > > >From just this text, I can't tell if this is describing the mechanisms of
> > > this document or an existing Auto-Bandwidth feature that is related to
> > > the mechanisms of this document.
> > >
> >
> > The auto-bandwidth feature without PCE exists, where the ingress does
> > the measurement as well as path computation. This feature has been
> > implemented long back but was not part of any standard because it was
> > a local implementation at the ingress node and no protocol changes was
> > required. With the PCE things changed and here we are...
>
> Ah, I see.  Maybe "This feature, when available in the head-end LSR
> implementation, is common referred to as [...]", then?
>

Updated.


> > > Section 2.3
> > >
> > > Are we assuming any relationship between the Up-Adjustment-Threshold and
> > > the Overflow-Threshold?
> > >
> >
> > Yes, as mentioned here while describing Overflow-Threshold -
> >
> >       The LSP bandwidth is adjusted to the
> >       current bandwidth demand bypassing the Up-Adjustment-Interval if
> >       the overflow condition is met consecutively for the Overflow-
> >       Count.
>
> I was thinking more along the lines of if the Overflow-Threshold value was
> going to be a larger number than the Up-Adjustment-Threshold.
>

Yes, I have added this in terminology section.
Also added a note for operator to take care while setting this in section 6.1.

I prefer to keep this generic as there are multiple combinations of
formats to deal with.

> >
> > >       traffic demand.  If the percentage or absolute difference between
> > >       the current MaxAvgBw and the current bandwidth reservation of the
> > >       LSP is greater than or equal to the threshold value, the overflow
> > >       condition is set to be met.  The LSP bandwidth is adjusted to the
> > >
> > > nit: I think s/set to be met/said to be met/ ?  (this appears twice)
> > >
> >
> > Ack
> >
> > >    Minimum-Threshold:  The increase or decrease of the LSP bandwidth
> > >       should be at least or above the minimum-threshold represented as
> > >       an absolute bandwidth value before the bandwidth adjustment for
> > >       the LSP is made.  This threshold can be seen as a suppression
> > >       threshold that is used along with a percentage threshold to avoid
> > >       unnecessary auto-bandwidth adjustments and re-signaling of the LSP
> > >       at low bandwidth values.
> > >
> > > I can't tell from this text if this threshold is a (LSP) bandwidth
> > > value/measurement or a bandwidth offset between configured and measured
> > > values.  (The subsequent protocol element definitions are more clear
> > > that it's the latter.)
> > >
> >
> > It is latter. Do you have a suggested change, I am not sure what change to make.
>
> How about:
>
>    Minimum-Threshold:  When percentage-based thresholds are in use, they
>       are accompanied by this minimum threshold, which is used to enforce
>       that the magnitude of deviation of calculated LSP bandwidth from the
>       reserved bandwidth exceeds a specific non-percentage-based criterion
>       before any adjustments are made.  This serves to suppress unnecessary
>       auto-bandwidth adjustments and re-signaling of the LSP at low
>       bandwidth values.
>
>

Thanks for the text. Updated with minor changes.

> > > Section 4.2
> > >
> > >    When the Auto-Bandwidth feature is enabled, the measured traffic rate
> > >    is periodically sampled at each Sample-Interval (which can be
> > >    configured by an operator and the default value as 5 minutes) by the
> > >    PCC, when the PCC is the head-end node of the LSP.  The traffic rate
> > >
> > > Do we cover what happens in the case when the PCC is not the head-end
> > > node of the LSP?
> > >
> >
> > No.
>
> Should we document that somewhere?
>

Added.

Diff: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-stateful-pce-auto-bandwidth-11&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt

Working Copy: https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt

Thanks!
Dhruv