Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 23 February 2017 10:34 UTC

Return-Path: <adrian@olddog.co.uk>
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 CD7BA1296AE; Thu, 23 Feb 2017 02:34:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 H7cDSceHjM55; Thu, 23 Feb 2017 02:34:03 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC701296A1; Thu, 23 Feb 2017 02:34:02 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1NAXshj020877; Thu, 23 Feb 2017 10:33:54 GMT
Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1NAXotX020861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2017 10:33:53 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Dhruv Dhody' <dhruv.dhody@huawei.com>, 'Jonathan Hardwick' <Jonathan.Hardwick@metaswitch.com>, pce@ietf.org
References: <BY2PR0201MB191078869D7F31052330053284600@BY2PR0201MB1910.namprd02.prod.outlook.com> <04d801d271c7$75a51770$60ef4650$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B8CA6247C@blreml501-mbb> <082c01d27988$9c30e950$d492bbf0$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B8CA62780@blreml501-mbb> <23CE718903A838468A8B325B80962F9B8CA7500F@blreml501-mbb>
In-Reply-To: <23CE718903A838468A8B325B80962F9B8CA7500F@blreml501-mbb>
Date: Thu, 23 Feb 2017 10:33:52 -0000
Message-ID: <067401d28dc0$55ad6570$01083050$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIr/eg1Q9mZk8qgpXnDhlnKP/1QeALisXMGAYJ7SLYBvd0TpQHdfopcAhb5lAOgcsi64A==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22902.006
X-TM-AS-Result: No--15.171-10.0-31-10
X-imss-scan-details: No--15.171-10.0-31-10
X-TMASE-MatchedRID: oHOSwQSJZWinykMun0J1wvHkpkyUphL9Ud7Bjfo+5jTM9X6l99fFT3eR +gIsfN9AOY5vwWpeQsBiPmy8WTo67mob6A84c/fI2MMmxTWvrZu5JJEy92I4jCRwmEMDEuwZTVe /MsxLuMAsm08AFnP7irIukFeJn/9AcNf8KQA4w7xor4yxPAz7WUNphebivZBYCTaA+uwR5t8q1n Wfko5RGYxiQgtW5pQ9VBcMAm2b6Q06q0cNvkl2ilaOpp/sV5nVhV0srjoqtx+na6U74e0+qALyt DvV39h+FqzzhFk7BYZf8868kEpnmStg+qZmq1X/QpxiLlDD9FUxmbT6wQT2aznKpbGL4ChVHACU cDvcWyAcl4Vrs6KMmHJkCGHrg33EMNaqmAxHBiRswYo64ufkVSMSJEhzxGu9kapCDmBfYkly3yC VHtn3QIX5qeuCEtpocAjp+XhH9sndWSaa0iXMMJ4CIKY/Hg3AY2fxc+IAshv6APa9i04WGCq2rl 3dzGQ1zAYCMArxFLAzwt80PodM3UEtchC63boUkQiFGO5KmKZuJImNnvU7nmunJiG40iC4
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/LuGMPuuAfJDKLcYTBLBSH8Us0uE>
Cc: draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org, pce-chairs@ietf.org
Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Thu, 23 Feb 2017 10:34:05 -0000

Thanks.
Wfm.
A

> -----Original Message-----
> From: Dhruv Dhody [mailto:dhruv.dhody@huawei.com]
> Sent: 23 February 2017 06:58
> To: 'adrian@olddog.co.uk'; 'Jonathan Hardwick'; 'pce@ietf.org'
> Cc: 'pce-chairs@ietf.org';
'draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org'
> Subject: RE: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-
> bandwidth-09
> 
> Hi Adrian, WG,
> 
> This is an update for the two open issues -
> 
> [snip]
> 
> > > >> ---
> > > >> Did you consider allowing a different Adjustment-Interval for
> > > >> adjustment up and adjustment down (with them defaulting to the same
> > value)?
> > > >
> > > > [Dhruv] No, it is not supported by most of the vendors.
> > >
> > > ROFL
> > > It's not even a WG draft yet.
> > >
> >
> > [Dhruv] :) I meant, for the existing implementation of auto-bandwidth
> > feature with local CSPF. Anyways...
> >
> > > > They keep the same interval but allow setting of different values
> > > > for the overflow and underflow threshold/count. Do you feel that
> > > > this should be added?
> > >
> > > Not sure. If I was writing the code, I would certainly have used two
> > > different timers because that is cheap and easy and flexible. Whether
> > > I would have exposed both as configurable in the first release is
> > debatable.
> > >
> > > If I was deploying I think I would want to experiment with making
> > > changes more sticky in one direction than in the other direction. How
> > > important that is might depend on how expensive it is to increase b/w
> > > once it has been reduced, and how likely it is that an increase might
> > fail.
> > >
> >
> > [Dhruv] Understood. I will keep this point open in the current version and
> > gather feedback from my co-authors as well as operators, before updating.
> >
> 
> [[Dhruv Dhody]] Authors discussed this point and concluded that this
flexibility
> could be quite useful. And thus have added separate interval and threshold for
> up and down -
> 
> - Up-Adjustment-Interval
> - Down-Adjustment-Interval
> - Up-Adjustment-Threshold
> - Down-Adjustment-Threshold
> 
> 
> > > >>---
> > > >> 4.2 has
> > > >>
> > > >> All thresholds in this document could be represented in both
> > > >> absolute value and percentage, and could be used together.
> > > >>
> > > >> I looked but couldn't find. If absolute and percentage are both
> > > >> supplied and imply different thresholds, which one is used? Could
> > > >> be as simple as "the first threshold hit", but this could lead to
> > > >> some flaps that are not obvious to someone staring at either the
> > > >> up/down percentage thresholds or at the up/down absolute values.
> > > >
> > > > [Dhruv] In section 5.2.3 (and similarly 5.2.5) states -
> > > >
> > > > An implementation MAY include both
> > > > sub-TLVs for the absolute value and the percentage, in which case
> > > >the bandwidth is adjusted when either of the adjustment threshold
> > > >  conditions are met.
> > > >
> > > > Which is similar to what you state.
> > > > Do you suggest we add some guidelines to provide information on
> > > > which threshold is met by logging?
> > > > Or do you feel strongly about this and we should use only one format?
> > >
> > > I think that this may be flexibility too far. I can't see a way that
> > > this would break anything, but might lead to "unexpected" results. For
> > example...
> > >
> > > Up % = 1%
> > > Down % = 10%
> > > Up absolute = 1 GB
> > > Down absolute = 1 MB
> > >
> > > This would cause wibbles, but maybe that is what the operator has asked
> > for.
> > >
> > > But maybe nothing more to say.
> > >
> > >
> >
> > [Dhruv] Personally I am fine either way. I will update once I get a
> > confirmation from my co-authors.
> >
> 
> [[Dhruv Dhody]] We would like to keep this flexibility as it useful when the
LSP
> bandwidth becomes large or small, and optionally providing threshold in both
> absolute and %age is useful.
> Consider we set overflow threshold as either 20% or 500M.
> When tunnel gets large (say 10G), the 20% is 2G, which is too large a
threshold
> and thus 500M as an absolute value helps, but when the same tunnel is small I
> would like 20% threshold to be applied, even when it is less than 500M.
> 
> We have clarified this in the latest version.
> 
> The diff is attached, it also includes some editorial changes.
> 
> Thanks again for your detailed review comments.
> 
> Regards,
> Dhruv (on behalf of co-authors)