On Thu, Dec 6, 2018 at 7:18 AM Stewart Bryant <stewart.bry...@gmail.com> wrote:
> > > On 06/12/2018 07:55, Dongjie (Jimmy) wrote: > > Hi Spencer, Stewart, Joel, > > > > Thanks for the discussion about the congestion adaptation. We agree the > reactive congestion adaptation may need further investigation. > > > > Thus in order to solve Mirja's comment, we plan to make that example > more generic with something like: > > > > "For example, the collected information could be used for traffic > monitoring, and could optionally be used for traffic optimization according > to operator's policy." > > Sounds much better. > I defer to Mirja since this is her ballot, but that sounds much more sane to me :-) Thanks for considering my comment on Mirja's comment! Spencer > Stewart > > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:j...@joelhalpern.com] > >> Sent: Wednesday, December 05, 2018 12:03 AM > >> To: Spencer Dawkins at IETF <spencerdawkins.i...@gmail.com>; Stewart > >> Bryant <stewart.bry...@gmail.com> > >> Cc: opsawg-cha...@ietf.org; opsawg@ietf.org; Mirja Kuehlewind > >> <i...@kuehlewind.net>; IESG <i...@ietf.org>; > >> draft-ietf-opsawg-ipfix-bgp-commun...@ietf.org > >> Subject: Re: [OPSAWG] Mirja Kühlewind's No Objection on > >> draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT) > >> > >> The conclusion earlier work on congestive response routing reached was > that > >> one needed to pin the specific routing decision until the selected path > became > >> infeasible. > >> > >> Yours, > >> Joel > >> > >> On 12/4/18 10:59 AM, Spencer Dawkins at IETF wrote: > >>> Hi, Stewart, > >>> > >>> On Tue, Dec 4, 2018 at 6:07 AM Stewart Bryant > >>> <stewart.bry...@gmail.com <mailto:stewart.bry...@gmail.com>> wrote: > >>> > >>> > >>> > >>> On 30/11/2018 19:23, Spencer Dawkins at IETF wrote: > >>>> This is Mirja's comment, but ... > >>>> > >>>> On Fri, Nov 30, 2018 at 10:12 AM Mirja Kühlewind > >>>> <i...@kuehlewind.net <mailto:i...@kuehlewind.net>> wrote: > >>>> > >>>> Mirja Kühlewind has entered the following ballot position for > >>>> draft-ietf-opsawg-ipfix-bgp-community-11: No Objection > >>>> > >>>> When responding, please keep the subject line intact and > reply > >>>> to all > >>>> email addresses included in the To and CC lines. (Feel free > to > >>>> cut this > >>>> introductory paragraph, however.) > >>>> > >>>> > >>>> Please refer to > >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html > >>>> for more information about IESG DISCUSS and COMMENT > >> positions. > >>>> > >>>> The document, along with other ballot positions, can be found > >>>> here: > >>>> > >>>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-communit > >>>> y/ > >>>> > >>>> > >>>> > >>>> > ---------------------------------------------------------------------- > >>>> COMMENT: > >>>> > >>>> --------------------------------------------------------------------- > >>>> - > >>>> > >>>> One comment on section 1: > >>>> "For example, they can shift some flows > >>>> from congested links to low utilized links through an SDN > >>>> controller > >>>> or PCE [RFC4655]." > >>>> I'm not aware that ipfix information is commonly used for > >>>> dynamic traffic > >>>> adaptation and I'm not sure that is recommendable. C > >>>> > >>>> > >>>> I'm agreeing with Mirja here. > >>>> > >>>> We've spent a LOT of time not recommending dynamic traffic > >>>> adaptation. Probably half my responsibility as AD for ALTO was > >>>> repeating "you can't react based on changes to that attribute > >>>> without taking chances on oscillation" like it was a mystical > >>>> incantation, and I wasn't the first AD to have that conversation > >>>> repeatedly. > >>> Yes, I understand the ARPA net had exactly that problem at one > stage > >>> and had to be converted from using a delay based metric to a fixed > >>> metric. > >>> > >>>> I would be happy to hear that all those problems are solved, but > I > >>>> haven't heard that yet. Do the right thing, of course. > >>>> > >>>> Even "can shift some flows from persistently congested links to > >>>> underutilized links" would cause me less heartburn. > >>> There is no such thing as permanent in network paths! > >>> > >>> Like many control problems the first order solution is to damp > with > >>> a suitably long time constant, but infinity, i.e. permanent, is > not > >>> a satisfactory choice either. > >>> > >>> > >>> Yeah, that's where I was headed (stated more coherently). > >>> > >>> Saying "I should do something, because the network path is STILL > >>> congested" is safer than "I should do something because the network > >>> path is congested", so now we're talking about suitable definitions of > >>> "STILL". I was shooting for that with "persistent", and agree that > >>> "permanent" path characteristics is a happy idea we aren't likely to > >>> see in practice. > >>> > >>> Do the right thing, of course ;-) > >>> > >>> Spencer > >>> > >>> - Stewart > >>> > >>>> Spencer > >>> > >>> > >>> > >>> _______________________________________________ > >>> OPSAWG mailing list > >>> OPSAWG@ietf.org > >>> https://www.ietf.org/mailman/listinfo/opsawg > >>> > >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
