Re: [Lsr] Dynamic flow control for flooding

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 24 July 2019 18:27 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 0D20F1202A5 for <lsr@ietfa.amsl.com>; Wed, 24 Jul 2019 11:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, URIBL_BLOCKED=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=HeDYn3GM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=j0yhw4gu
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 RgeP-2DTL9pM for <lsr@ietfa.amsl.com>; Wed, 24 Jul 2019 11:27:47 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9949C12017F for <lsr@ietf.org>; Wed, 24 Jul 2019 11:27:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16360; q=dns/txt; s=iport; t=1563992866; x=1565202466; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iA2/2AKIGwqZ7V76DjQiEcqYr0reQV+sgKMjGJmPzTs=; b=HeDYn3GMZyMT+p/yynZ78IRCcaYE9cSjD/13EkVjyOglo8C2yuJ9jvwf XZRoigg6OC6Lpv2AUfPyHkh+rwojOFPugAD8b3H7izgJJUI/SwFnSoJpj XHaAABw0bMg+O8bB06KIFfmir2d2w+S2tts3HRP/6zdDKo9hZoXGVHWSJ o=;
IronPort-PHdr: 9a23:P5chRhxbaDpJ7uDXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZuKCEvgJvPwYAQxHd9JUxlu+HToeUU=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ApAACrojhd/5JdJa1mGgEBAQEBAgEBAQEHAgEBAQGBVgIBAQEBCwGBFC8pJwNtVSAECyqEHYNHA4x8gluJVIknhFWCUgNUCQEBAQwBAS0CAQGEQAIXgkIjNwYOAQMBAQQBAQIBBm2FHgELhUoBAQEBAxIRChMBATcBDwIBBgIRBAEBKwICAh8RHQgCBA4FCBqDAYEdTQMdAQKRB5BgAoE4iGBxgTKCeQEBBYUHDQuCEwmBNAGLXxeBQD+BEUaBTlAuPoIagiwVgnQygiaMJDOCJYR/iC0/jUhACQKCGZAZhBKCLYcljjiNN4k/jhUCBAIEBQIOAQEFgWYigVhwFTuCbIJCgSYBCYJBg0aHDXKBKY4AAQE
X-IronPort-AV: E=Sophos;i="5.64,303,1559520000"; d="scan'208,217";a="601504766"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2019 18:27:44 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x6OIRiqt008691 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jul 2019 18:27:44 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 13:27:43 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 13:27:43 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Jul 2019 14:27:42 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lU789GX9r73zAfSfZKK8DsyV4moFsK8URkUhBGm4pGyb6OctMPIjQqLTQpZQwPJtbxg4PfVLxzXhV5QTcP6AyIcaoTkoKQ64o1HEA+yTrxN1AC9ZrvYOoLPNc1H1ydvNNDg2z50I++Wf9/4DGp9n4wV0agZZXPo89cvGhMcKo/XSWyfzhK3SP6TMUS+2yPhEEqjIdTqakvqcfRBJkGjFnwDdlUfVAoR+8F8H+6LzGPIOLQU+UjKR9iVlqB1UIVN8F6ty+t71Y7Vgt+bDhp7nYv6R06c95+QkJcoNJuKtURq7lWOEbYCB1B7jfnvzIwf67xY3+SwF8FtrcKe4m4/LQg==
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=iA2/2AKIGwqZ7V76DjQiEcqYr0reQV+sgKMjGJmPzTs=; b=RfKufaLpNmVin49qH10OyST/hfiTJqcU/e9nxHaIejxWkoRzFfg8RNwQTnAMH40jTfBHby/2+Z9TBVVkSU950zBIDVP66sE8QvI4EQbWkLAkjMWnvbisMfuXvFAS5xu71+fupQ1GVXFsvFqs6ip+QaZUgso1d3TtFEf168CDfYhFn41+XOlDHTxTuXASkNFIVD8965lJ/PArHkOJACgtuvX9KJaRbTV3HlsW9Xhw66QI73/zLHp/nZVscD9oS1o77ZPfSytMZgy3meEGp9l+FCXL1yDjyuGL1rLezgGdsQFqZlQ49KJ1BjadjfwywcA56i7MsW3/fRdH4ttwSS6T9w==
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=iA2/2AKIGwqZ7V76DjQiEcqYr0reQV+sgKMjGJmPzTs=; b=j0yhw4gua1iEBNq4/SDHNezk+AkCuENNMnosDTZeVlQKAgRGrSLzLjheZuKf2ObU2U3m2s+mKJkNKy7dNsb3mwVln+CYbtdsZ2ONIra+gIkH2zw+ppYxi8p9cFUyLUzG24AOD2MU98PPDxX36fAGzypWCYhfuc0+utd0Xj5fsgg=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2742.namprd11.prod.outlook.com (52.135.227.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Wed, 24 Jul 2019 18:27:41 +0000
Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::c8b3:b0b0:581d:e1ce]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::c8b3:b0b0:581d:e1ce%6]) with mapi id 15.20.2115.005; Wed, 24 Jul 2019 18:27:41 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "tony.li@tony.li" <tony.li@tony.li>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Dynamic flow control for flooding
Thread-Index: AQHVQVt0dc+yhfYADEyrMMJ609g9uKbYO7RggAEF1QCAANNGsA==
Date: Wed, 24 Jul 2019 18:27:41 +0000
Message-ID: <BYAPR11MB36381F5B3EC20BC8BE2217D5C1C60@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <CAMj-N0LdaNBapVNisWs6cbH6RsHiXd-EMg6vRvO_U+UQsYVvXw@mail.gmail.com> <BYAPR11MB36382C89363202D1B5659614C1C70@BYAPR11MB3638.namprd11.prod.outlook.com> <593D6ED8-A568-4B41-8882-3D32A6D0111F@tony.li>
In-Reply-To: <593D6ED8-A568-4B41-8882-3D32A6D0111F@tony.li>
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:1006::374]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7586bccb-ea6b-4403-88a0-08d710649d02
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2742;
x-ms-traffictypediagnostic: BYAPR11MB2742:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR11MB27420C991F8ACA02F1F6480EC1C60@BYAPR11MB2742.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(396003)(376002)(39860400002)(136003)(199004)(189003)(33656002)(53936002)(54896002)(6436002)(55016002)(2501003)(2351001)(9686003)(5640700003)(790700001)(2906002)(6306002)(486006)(8936002)(6116002)(68736007)(25786009)(102836004)(6506007)(53546011)(76176011)(478600001)(7696005)(11346002)(446003)(46003)(66476007)(4326008)(81166006)(99286004)(6916009)(74316002)(8676002)(316002)(7736002)(256004)(229853002)(71200400001)(52536014)(76116006)(5660300002)(186003)(86362001)(14454004)(476003)(66946007)(71190400001)(66556008)(6246003)(66446008)(64756008)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2742; H:BYAPR11MB3638.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-message-info: 1kzOIALvX4sgVTLSIisi6KYI9eP+VgCkglHW6fzO/KUfDGi7q45RY6rQsdEvlEqHOmbuKjSJ7TjsfVr7Rj3S/Xb2L9kMFl9vXS7H7j+9td+2gu8qt6nwI9CbY/3X2phYb20P9TmhcnPDnG7XgmrgQSpxIUNaKl1IJI2bB7gTMQR08fHQyp5gEyIOJWQzSQP6BxeLQWq4ACUsYs7mR/51NyBYwYg47Ge1cA3H0WkkCmr4mPs1Lg+Ql2WUm+WFxIBG2yAfP4gtBDwpwBg/zuU38RPcqshMGAkoVl2L3ISpP0lITSTwHk/HqexTLMtWaRoFMBChOrH2iXgaRljASdNem58FbRIloeQBmmP4onmEjTMrAuDFGnzYIWtB6NGRYotznKZc3TdJegXaGRbkl5rO695pVkju+KAKMcuQA5mqNyw=
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB36381F5B3EC20BC8BE2217D5C1C60BYAPR11MB3638namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7586bccb-ea6b-4403-88a0-08d710649d02
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 18:27:41.1988 (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: ginsberg@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2742
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/dlIqudmgGDVB7FAwkZ28ynPUwns>
Subject: Re: [Lsr] Dynamic flow control for flooding
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, 24 Jul 2019 18:27:50 -0000

Tony –

Inline.

From: Tony Li <tony1athome@gmail.com> On Behalf Of tony.li@tony.li
Sent: Tuesday, July 23, 2019 10:39 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding



Les,

I also think we all agree on the goal - which is to flood significantly faster than many implementations do today to handle deployments like the case you mention below.


I agree with that, but you haven’t responded to the goal that I proposed: keep the receiver processing PDUs.

[Les:] My goals are:

Optimize convergence.
Minimize complexity.

Optimizing the throughput through a slow receiver is pretty low on my list because the ROI is low.


Beyond this point, I have a different perspective.

As network-wide convergence depends upon fast propagation of LSP changes – which in turn requires consistent flooding rates on all interfaces enabled for flooding – a properly provisioned network MUST be able to sustain a consistent flooding rate or the operation of the network will suffer. We therefore need to view flow control issues as indicative of a problem.

It is a mistake to equate LSP flooding with a set of independent P2P “connections” – each of which can operate at a rate independent of the other.

If we can agree on this, then I believe we will have placed the flow control problem in its proper perspective – in which case it will become easier to agree on the best way to implement flow control.


I agree that we want network wide convergence.  However, I disagree that the right thing to do is to uniformly flood at the same rate on all interfaces.

First, the rate that you select might be too fast for one neighbor and not for the others.  Real flow control would help address this.

[Les:] At the cost of convergence. Not a good tradeoff.
I am arguing that we do want to flood at the same rate on all interfaces used for flooding. When we cannot, flow control does not help with convergence. It may decrease some wasted bandwidth – but as we all agree that bandwidth isn’t a significant limitation this isn’t a great concern.

The same reasons that drive us to use same SPF delay and LSP Generation timers on all routers also apply to flooding rate.

Second, all flooding paths are not created equal.  You do not know, a priori, how to flood to get uniform network wide propagation.  The variance in CPU loading alone is going to cause different routers to flood at different rates, and so it may actaully be optimal to flood quickly down one path, knowing that the data will reach the other end of the network and flood back before the slow CPU can absorb and flood.

[Les:] I do not see how flow control improves things.
If you have alternate flooding paths around the slow link(s) this argues more that you should not have the slow link in the flooding topology in the first place. But this heads off topic – I think we agree that dynamic flooding is a separate discussion which we don’t want to bring into this thread.

Dropping down to the least common denominator CPU speed in the entire network is going to be undoable without an oracle, and absurdly slow even with that.

[Les:] Never advocated that – please do not put those words in my mouth.

   Les


Tony