Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 19 February 2020 22:01 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DFF12022E for <lsr@ietfa.amsl.com>; Wed, 19 Feb 2020 14:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IiK80kTW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hSnvh8Os
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 3pjgE99asZGj for <lsr@ietfa.amsl.com>; Wed, 19 Feb 2020 14:01:23 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FAB12083D for <lsr@ietf.org>; Wed, 19 Feb 2020 14:01:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22782; q=dns/txt; s=iport; t=1582149683; x=1583359283; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AOMftRQLFEcPgtOQVZ2b47GIOVzHc3Jb6/P26pBB+Wo=; b=IiK80kTW/OI36rWoYSSjilI5D8OBultnMuRU3Yi7cRrS7GHXakI5+0kH 8Gvz4/id1yEMopXdydOP25vuTVvksaCtFeiFe2x2fdthcj55X48D8o9QT uCqvdYNf3DMTC6RZAkHaw4Q9UV9pd9QFqqIrE+bZ7ONfgtNdzDfOHBzht Q=;
IronPort-PHdr: 9a23:4N70iRwpUHUDAjTXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZuKCEvgJvPwYAQxHd9JUxlu+HToeUU=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BGAQD7rk1e/5ldJa1mGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF7gSUvJAUnBWxYIAQLKoQUg0YDinCCX4liiU6EYYJSA1QJAQEBDAEBGAEKCgIEAQGEQAIXgW0kOBMCAw0BAQUBAQECAQUEbYU3DIVmAQEBAQMBARARChMBASwLAQsEAgEGAhEBAwEBAScDAgICHwYLFAMGCAIEDgUIEweDBYF9TQMuAQIMklmQZwKBOYhidYEygn8BAQWFKA0LggwDBoE4jCQagUE/gRBIgU5QLj6CG0kBAYFnFQ8HCYJaMoIsjUYWQYJGhXCJN49HRAqCO40chQ6EUoJJiBuQR5A8iVqQHgIEAgQFAg4BAQWBaSKBWHAVO4JsUBgNjh2BJwEHAoJCg0aBToU/dIEpjWoBAQ
X-IronPort-AV: E=Sophos;i="5.70,462,1574121600"; d="scan'208,217";a="432663964"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Feb 2020 22:01:21 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 01JM1Lq5013425 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Feb 2020 22:01:21 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Feb 2020 16:01:20 -0600
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Feb 2020 17:01:19 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 19 Feb 2020 16:01:19 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dtITaxF8iBKgcCTMyq9+kN7V8kjxwDe1qHD7E3DQNrUA9h9LGyN+rKZUme8Iqu9K5nfgr2UIwysww68PZLnh9l1prYNHFrrVX7JMy6DfYT7IXEKrGEV3t4HsFhFHnSM7YQ+eqK+oOiOaHNP4FVvzXE6DF9CxaB3PHCJnNY6CtOttV3NSmFJRwihzyYfOF4ZA+rdqfqTQ2SuEpBbKQ7iRR05ZFs5VNc7An8DJMxoI5GHajeR5JJq7MqRk9Qn03sQQkYTerHsWAg/7yNA4k8DRFcPQfnjz2qfCjDpLq7kcEGJBnJlGtnTLpmEnNGw2hUfGNlyA626QWIlkvPGWZXd0/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AOMftRQLFEcPgtOQVZ2b47GIOVzHc3Jb6/P26pBB+Wo=; b=PV2QtgwnV2Ny/vd3IpoROJMFOJPDO8UAqpprIDhlty3/eLemaaRwFMoLkkEcSQU1jiCpTms1DTBXv4+BrS5uCMfhdMxrWoUTPHoF2fzAIoRx32wQ9aE0nPI34wBeK3Si/CQ3JvjSpR8wpGkmjXl3eVcLxWHpFsJ0Atx2jzqDSLVV7A9P/gccryE7Yxzxb7RUXlYTQPCFKMvruXD1Io4V4t3hfd8m/POam8yuD81whSD2WkuASBZiyc1dNMCEeLoRkR4mdXpBw9XKqzT0gjESbDezUiUj/DvERDAZvk17ReyHCf+TPsEe6GxRXsYdG+Q4ccZlzrusofeaHoPIp5RsLw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AOMftRQLFEcPgtOQVZ2b47GIOVzHc3Jb6/P26pBB+Wo=; b=hSnvh8OsXdYzNfbpgXTX95g2p5h22PcGxll/VgqAqoM3vqJBCRA/mv6pjGnkZYSORTCPPPt04Lq1w1vWd1qB7NzBE7H6dluL4D0DzoOdLfzxOjd/9TxdhUg9LLxZoyE7Ooiznzgc6oJDXrXnuyJgGF6yGrW8fjUcfa3KYohDKV8=
Received: from MW3PR11MB4619.namprd11.prod.outlook.com (20.181.54.207) by MW3PR11MB4716.namprd11.prod.outlook.com (20.181.52.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Wed, 19 Feb 2020 22:01:18 +0000
Received: from MW3PR11MB4619.namprd11.prod.outlook.com ([fe80::b87d:76f6:5a2e:951c]) by MW3PR11MB4619.namprd11.prod.outlook.com ([fe80::b87d:76f6:5a2e:951c%3]) with mapi id 15.20.2729.032; Wed, 19 Feb 2020 22:01:18 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Tony Przygienda <tonysietf@gmail.com>
CC: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, Tony Li <tony1athome@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, "tony.li@tony.li" <tony.li@tony.li>
Thread-Topic: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
Thread-Index: AdXmy57fbkJZPBB7TgK3RmmTteJ+KgABmiUAAAXBVGAAALvbAAAADcCwAADjzIAAAE+xoAACI1mAAAI47oAAAS4LAAAAfQaAAAAcA4AAAMOnAAABAHOAAABnkAAADqtI8AADVj8AAAVfEOA=
Date: Wed, 19 Feb 2020 22:01:18 +0000
Message-ID: <MW3PR11MB46194A956A31261459526B43C1100@MW3PR11MB4619.namprd11.prod.outlook.com>
References: <5b430357-56ad-2901-f5a8-c0678a507293@cisco.com> <4FC90EB2-D355-4DC5-8365-E5FBE037954E@gmail.com> <f5b56713-2a4d-1bf7-8362-df4323675c61@cisco.com> <MW3PR11MB4619C54F5C6160491847AA45C1100@MW3PR11MB4619.namprd11.prod.outlook.com> <CA+wi2hMH1PjiaGxdE5Nhb2tjsZtCL7+vjxwE+dk9PWN1fyz7vQ@mail.gmail.com>
In-Reply-To: <CA+wi2hMH1PjiaGxdE5Nhb2tjsZtCL7+vjxwE+dk9PWN1fyz7vQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com;
x-originating-ip: [2001:420:c0c8:1005::756]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 871605fb-259d-4a6d-aee1-08d7b5873f6c
x-ms-traffictypediagnostic: MW3PR11MB4716:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MW3PR11MB4716EA0C24AD632F8FA0F9CCC1100@MW3PR11MB4716.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0318501FAE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(366004)(39860400002)(136003)(199004)(189003)(6916009)(966005)(9686003)(71200400001)(33656002)(2906002)(55016002)(478600001)(316002)(81156014)(53546011)(86362001)(8676002)(66946007)(66446008)(186003)(4326008)(7696005)(81166006)(54906003)(5660300002)(66476007)(52536014)(6506007)(76116006)(8936002)(66556008)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:MW3PR11MB4716; H:MW3PR11MB4619.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: a3HSC4S2Ewn+iMZQ+4+X9JjxF/PJh505L6tPHcTOc5RjBwTZQ7Oj0K9gINajXEU9BnrUGuYHyjqD8eyNyGp+Q3iTy2TNqzD7s8sS/2ifySZwK5Y+/9A4vA9StFtgbVk+MEpwUWnZU2H747wUMfo1DE+vgDbBz/n+cPsY01Upd+fD340NzslWJngqp9DTd3y40KBBhadHyICcxQOLhQTs4JHSR2Z2Q3okPHGrzrFwwU7wJri11z8vksplvPN/DnfoFsUL69oYZJianXqPFARER6YbG1Dy0Ba3qjYCjpfLXsJU5BAotcd8L22UinXDbbgh3EzR84E8RoQWLSWHeeXJGAkIVe+CtdloaDtQORBXw63ucQHovCAqPUhmVF1TcsEYz1n396sGpwMunbtJ713iMn/Aajig8jTzeR32Bc/XZky4yDKcgd1QMmDYmI8VaZX0iRKZu0AKuW3dh70AnQ3W5kpbXUmp/R64KAJvwkK4FQUgT/oGKDZ0ZzRHU3Rnc5q3IOGZWNACkvMCcF8SeYliAA==
x-ms-exchange-antispam-messagedata: frZDAfNEi2MIdOkgrOx/XhTV1MWas6YXsbVvNgvo9ZuwtT4k8w+3UBYhQS0cNlU/XTc9wqzJ2npbLPwWHMjRQUu+RBbSy43iQJUuVcV8YHNY4EAegdPvOLkkr0cPBrxZTLB+kf0kSOm0vTH5ljmGmHfnIMZwel6lVmqqkT9UXYs=
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB46194A956A31261459526B43C1100MW3PR11MB4619namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 871605fb-259d-4a6d-aee1-08d7b5873f6c
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2020 22:01:18.4667 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Z9R5lQjIKuvVp7T4pJ+Y47+r2mmT2YCu7qmKFepwx8wyIU4LoAtz8LXfxeb5DbTdyOdcfpXEj4MxcGvGGRAe9A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4716
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/bNIYoHs2wPsdwa8Wu6FtinU3t2Y>
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2020 22:01:27 -0000

Tony –

If you have a suggestion for Tx back-off algorithm please feel free to share.
The proposal in the draft is just a suggestion.
As this is a local matter there is no interoperability issue, but certainly documenting a better algorithm is worthwhile.

   Les (claws in check 😊 )


From: Tony Przygienda <tonysietf@gmail.com>
Sent: Wednesday, February 19, 2020 11:25 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: Peter Psenak (ppsenak) <ppsenak@cisco.com>; Tony Li <tony1athome@gmail.com>; lsr@ietf.org; tony.li@tony.li
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Having worked for last couple of years on implementation of flooding speeds that converge LSDBs some order of magnitudes above today's speeds  ;-) here's a bunch of observations

1. TX side is easy and useful. My observation having gone quickly over the -ginsberg- draft is that you really want a better hysterisis there, it's bit too vertical and you will generate oscillations rather than walk around the equilibrium ;-)
2. Queue per interface is fairly trivial with modern implementation techniques and memory sizes if done correctly. Yes, very memory constrained platforms are a mildly different game and kind of precondition a different discussion.
3. RX side is possible and somewhat useful but much harder to do well depending on flavor. If we're talking about the RX advertising a very static value to cap the flooding speed that's actually a useful knob to have IMO/IME. Trying to cleverly communicate to the TXer a window size is not only fiendishly difficult, incurs back propagation speed (not neglectible @ those rates IME) but can easily lead to subtle flood starvation behaviors and lots of slow starts due to mixture of control loop dynamics and implementation complexity of such a scheme. Though, giving the TXer some hint that a backpressure is desired is however not a bad thing IME and can be derived failry easily without needs for checking queue sizes and so on. It's observable by looking @ some standard stats on what is productive incoming rate on the interface. Anything smarter needs new TLVs on packets & then you have a problem under/oversampling based on hellos (too low a frequency) and ACKs (too bursty, too batchy) and flooded back LSPs (too unpredictable)

For more details I can recommend rift draft of course ;-)

otherwise I'm staying out from this mildly feline spat ;-)

--- tony

On Wed, Feb 19, 2020 at 9:59 AM Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:
Tony -

Peter has a done a great job of highlighting that "single queue" is an oversimplification - I have nothing to add to that discussion.

I would like to point out another aspect of the Rx based solution.

As you need to send signaling based upon dynamic receiver state and this signaling is contained in unreliable PDUs (hellos) and to be useful this signaling needs to be sent ASAP - you cannot wait until the next periodic hello interval (default 10 seconds) to expire. So you are going to have to introduce extra hello traffic at a time when protocol input queues are already stressed.

Given hellos are unreliable, the question of how many transmissions of the update flow info is enough arises. You could make this more deterministic by enhancing the new TLV to include information received from the neighbor so that each side would know when the neighbor had received the updated info. This then requires additional hellos be sent in both directions - which exacerbates the queue issues on both receiver and transmitter.

It is true (of course) that hellos should be treated with higher priority than other PDUs, but this does not mean that the additional hellos have no impact on the queue space available for LSPs/SNPs.

Also, it seems like you are proposing interface independent logic, so you will be adjusting flow information on all interfaces enabled for IS-IS, which means that additional hello traffic will occur on all interfaces. At scale this is concerning.

   Les


> -----Original Message-----
> From: Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>
> Sent: Wednesday, February 19, 2020 2:49 AM
> To: Tony Li <tony1athome@gmail.com<mailto:tony1athome@gmail.com>>
> Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; tony.li@tony.li<mailto:tony.li@tony.li>;
> lsr@ietf.org<mailto:lsr@ietf.org>
> Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
> Tony,
>
> On 19/02/2020 11:37, Tony Li wrote:
> > Peter,
> >
> >> I'm aware of the PD layer and that is not the issue. The problem is that
> there is no common value to report across different PD layers, as each
> architecture may have different number of queues involved, etc. Trying to
> find a common value to report to IPGs across various PDs would involve
> some PD specific logic and that is the part I'm referring to and I would like
> NOT to get into.
> >
> >
> > I’m sorry that scares you.  It would seem like an initial implementation
> might be to take the min of the free space of the queues leading from the
> >interface to the CPU. I grant you that some additional sophistication may be
> necessary, but I suspect that this is not going to become more >complicated
> than polynomial evaluation.
>
> I'm not scared of polynomial evaluation, but the fact that my IGP
> implementation is dependent on the PD specifics, which are not generally
> available and need to be custom built for each PD specifically. I always
> thought a good IGP implementation is PD agnostic.
>
> thanks,
> Peter
>
> >
> > Tony
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org<mailto:Lsr@ietf.org>
> > https://www.ietf.org/mailman/listinfo/lsr
> >
> >

_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr