IETF Logo Mail Archive

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

tony.li@tony.li Mon, 27 April 2020 18:57 UTC

Return-Path: <tony1athome@gmail.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 B27BD3A18E2 for <lsr@ietfa.amsl.com>; Mon, 27 Apr 2020 11:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 MU1Mu4ZkFvrW for <lsr@ietfa.amsl.com>; Mon, 27 Apr 2020 11:57:55 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 6BAFE3A18DE for <lsr@ietf.org>; Mon, 27 Apr 2020 11:57:55 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id n24so7317389plp.13 for <lsr@ietf.org>; Mon, 27 Apr 2020 11:57:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=P182K+Q4RssUMtusSuyxWy2NT/zBUyme7E0dN1/EFeU=; b=tnNVtfydi8dWndC3nONSj+0sdFS3fOqsBnshGoyf7ImQ0rBwfIj0SCGPo7pn+QvZCf nwEaqcX7bF2cSDp1jbSiyLm29zcWBPiTr8D109GMfqrUnsATm9R/C4IQ6ByQ1910fbeu EEdnytOfNMv/3lEsJBJ5IWHdimmHRgNZTCyNUaP3pepsyjJHlUUywPehyH61OTwnoHrx vV/NrIe8G80yaYE5f6Ks0KhgAF6e1ruE1SpDNp4l0R4boKGHYz66RzpVae7HLL9irA2l PZ+oGN5EZFzFbh+6HlNXDsKCrHeSLUOjY98JH6xSp5AUJ5rlKa4HTCvjLrJvPBgr0Hey OPQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=P182K+Q4RssUMtusSuyxWy2NT/zBUyme7E0dN1/EFeU=; b=kUhRnay/lZb2VkoDqrOvzIWX4N5gjZbvCzJt1cho4F8D8sjh3Sxzzykx9S5q6wxJtY hm+ZHBpwjRZKo/GvfIwGss5T6JT9AcaHFO2FP0DJS+z2w+t3omd99+IoxxnG7oKdBPk+ hYRlSD3ttO1KgHJcezJJv+qwhuFu732EctPESLeXHXkk6nwAgmhri3ofpcu+C+9f441w ZinrmqJex+7s2iC2hkibILOSuRkyk7nzAr25r9S8z/9uH5qkjvgR+cb4TUoYSivERprS LYg4OPL0GQuynXZz9gSpjncyzB1zTXZDMiw2TTCm7l2yPJl+b/CJhSfl5iJs46B9jm1j EUtg==
X-Gm-Message-State: AGi0Puad6TQ2xhLx9vXhTgeo04/pxLFHUoLWke4VYm1Z/o4hHM1A01O9 xWxNxhKeNeb0BwwskER+xM4=
X-Google-Smtp-Source: APiQypKMEENB40/EtzMmgHS0BiyJg94c3LPOWv4pQqrwe0dbq0DEONX6QGNWzd/ptuPCBszTkdOfQA==
X-Received: by 2002:a17:90a:dc01:: with SMTP id i1mr128301pjv.166.1588013874691; Mon, 27 Apr 2020 11:57:54 -0700 (PDT)
Received: from [10.95.94.147] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id w125sm11428254pgw.22.2020.04.27.11.57.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2020 11:57:53 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <C0422461-48A6-4F41-A719-AC43909D78EF@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FF27E58F-C590-417C-9E2A-9F11B1181847"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 27 Apr 2020 11:47:32 -0700
In-Reply-To: <CAOj+MMEWGiwyG6oRdoE5HQdfzNkLK-E3dhBE_FvV=ysqod4Ftw@mail.gmail.com>
Cc: Bruno Decraene <bruno.decraene@orange.com>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Tony Przygienda <tonysietf@gmail.com>
To: Robert Raszuk <robert@raszuk.net>
References: <MW3PR11MB46191E81D5B22B454D8184A4C1100@MW3PR11MB4619.namprd11.prod.outlook.com> <MW3PR11MB461942C752F9CCB0A6E6C1BFC1100@MW3PR11MB4619.namprd11.prod.outlook.com> <13222_1587383221_5E9D8BB5_13222_339_1_53C29892C857584299CBF5D05346208A48E22AF0@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB46191D244D51A05F9AA4631DC1D50@MW3PR11MB4619.namprd11.prod.outlook.com> <CA+wi2hN2A3oZcZWngNjBnZ214jiGNfqyTZpytpK0jrxH68SnqQ@mail.gmail.com> <6448_1587578604_5EA086EC_6448_75_1_53C29892C857584299CBF5D05346208A48E26E6F@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CA+wi2hPd0Ccn_RiSf=EMa6BfPVhN5FnnOR2hz1PeWpMNNub-BA@mail.gmail.com> <19631_1587662111_5EA1CD1F_19631_99_1_53C29892C857584299CBF5D05346208A48E28EDE@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CA+wi2hMm=0C9LVy8po2eoYnrTRC6AKawoMJoDoEm5xtbFEvfhw@mail.gmail.com> <4008_1587720323_5EA2B083_4008_332_1_53C29892C857584299CBF5D05346208A48E29FE5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAOj+MMHJfkP5J_Jk+qpLi-VPwca-qwmezynKkKifqcyOxoZAsA@mail.gmail.com> <12067_1587976445_5EA698FD_12067_293_6_53C29892C857584299CBF5D05346208A48E2E14C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAOj+MMH6OZihneJjtH_PfXKfOh1ydTD4hQK3FfDJxjtRowMrRw@mail.gmail.com> <24062_1587989690_5EA6CCBA_24062_69_1_53C29892C857584299CBF5D05346208A48E2E517@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <4DE67B7F-A8E7-4595-8EB6-BED074C38B2F@cisco.com> <27097_1587992566_5EA6D7F6_27097_166_1_53C29892C857584299CBF5D05346208A48E2E687@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAOj+MMGENdGn-FB5GwkhsMZsTm_gQSYYmaGCyLy=5nAnCtvSRA@mail.gmail.com> <242BC3A4-0BD5-4F60-9B2F-3C9D1E7106E2@tony.li> <CAOj+MMF+jpfz0vsXum7eH=VTVzGA0dkbyXeQqnNwZ2uoibZ1hQ@mail.gmail.com> <59B46050-6F6B-4A9B-99CD-4E0C76FA17F2@tony.li> <CAOj+MMEWGiwyG6oRdoE5HQdfzNkLK-E3dhBE_FvV=ysqod4Ftw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/aDyKj2zcC40u2XMBg7qSU6Ey65M>
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: Mon, 27 Apr 2020 18:57:57 -0000

> If we have 1000 of interfaces and all peers *all in the same time* will send us an LSP of max size of 1492 octets that our control plane buffer RAM size required to store them would be as huge as 1.5 MB. And that assumes we did not process any from arrival of the first to the arrival of the last one. 


And that’s only one LSP.  If they don’t stop there and each sends 1000 LSPs, then you can have 10^6 incoming packets, requiring 1.6GB.

Further, since the bottleneck is likely the queue of packet on the forwarding chip(s) to the CPU, this 1.6GB needs to exist on the forwarding silicon.  Needless to say, it doesn’t.

Yes, the CPU can probably keep up with one of the peers. This implies that the forwarding plane queue grows at the rate that 999 peers are sending at. Thus, congestion.

Tony

v2.23.0 | Report a Bug | By Email