Re: [Lsr] Dynamic flow control for flooding

tony.li@tony.li Wed, 24 July 2019 05:02 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 DA4EF12011B for <lsr@ietfa.amsl.com>; Tue, 23 Jul 2019 22:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.559
X-Spam-Level:
X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, 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 0_1xPNuhtupq for <lsr@ietfa.amsl.com>; Tue, 23 Jul 2019 22:02:16 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 85D1A12003F for <lsr@ietf.org>; Tue, 23 Jul 2019 22:02:16 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id i18so20558799pgl.11 for <lsr@ietf.org>; Tue, 23 Jul 2019 22:02:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=x1m86LMaQxgzLeLs6POw5GpHjUjxm9FDI9upRskbXhk=; b=BDkN4gshXqR0hUk1OmREWpjldqXCgKp6JVG0MWBz06Zmb6SMF5A395nDLlvpf+yCtI h/cgss+PJCgMGV982u3RhTK7XhORAJr2SRpb7New7TBi8O8aDaLandvhOZuatnj27po5 v9r0G4d1AqCJein5442Gqz924BbKOjJFt2jphR52T/TluqKm2qPRy7CYhkH8+LuReiDK aNecAjKqgt0AZhvkRo6I2Z8ZSeFCneX8RYw3knc+SPxgC6XJ6zjtT6WPWnifJy3+ndtV 4GNQFR9t8VPXd04uOwizcJ4ZEzOg2XOK16yEWC2DDVODjbp9WvGy1j+w3AIzyaCHvVv3 Fqrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=x1m86LMaQxgzLeLs6POw5GpHjUjxm9FDI9upRskbXhk=; b=fP5IUMOAqiqAWHhDSbBLO4F7GH4a/4BdpUgRCV/EJmg4wDE3xzUgb30adybm4ClYhe /G3Auy6PGWdIl1YskAgPo37IB2BXSnuRMyfNJmySp3jOQrdqzg97YK7sa+CQt4AhwBns iVP+tvz91XAq7vkAbqL+qNP8SIgwIHDPNGByovEAwmQBaO4f1RLPX0z3W1rZtgn7AJb0 hraZpIF9qdtV1SuHZGpZKHOkU0uJQnw740Dzcfb6mlsCMaMTl0fwqnb8d0FUF/6d48Ui smRxRdVXg0KnSRuc8BNKd0wyNRiJkjXmGp2qRtm8oyj0XqomgwMeQaR4MiLZR3iskLk6 K1QA==
X-Gm-Message-State: APjAAAXix3isD1zqwsdDp9ggJexZRBgkLmi/w0po5AkNqBlmmTT7oDBS A9hfmPIz+fqrEHLIppaxAG0=
X-Google-Smtp-Source: APXvYqwTYfd6Wm3BblVluxdkFwZz+Ko4TunahNXMtSwqv6Ip4BgQia5bD2W5HimpyX0Li5GLiS9w7g==
X-Received: by 2002:a63:c750:: with SMTP id v16mr63244674pgg.320.1563944535924; Tue, 23 Jul 2019 22:02:15 -0700 (PDT)
Received: from [192.168.1.13] (c-73-158-115-137.hsd1.ca.comcast.net. [73.158.115.137]) by smtp.gmail.com with ESMTPSA id 10sm49330149pfb.30.2019.07.23.22.02.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 22:02:15 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: tony.li@tony.li
In-Reply-To: <CAOj+MMH02oUHtcJujparBVDo+-jS=WvYV50yVCgFsq=w=8BPMA@mail.gmail.com>
Date: Tue, 23 Jul 2019 22:01:51 -0700
Cc: "lsr@ietf.org" <lsr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2BBD860-327D-4601-9462-DB80CC0A4E13@tony.li>
References: <CAMj-N0LdaNBapVNisWs6cbH6RsHiXd-EMg6vRvO_U+UQsYVvXw@mail.gmail.com> <CAOj+MMH02oUHtcJujparBVDo+-jS=WvYV50yVCgFsq=w=8BPMA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/YnPFVHHoME6SUMMwTl9os0aF1oo>
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 05:02:18 -0000

Hi Robert,


> Are you working on the assumption that there is no data link layer flow control already which could signal the OS congestion on the receiving end ? 


I am assuming that there is no link layer flow control.  I can’t recall working on a system that supports X.25 since about 1995, so I don’t think that’s a common use case today. 


> Are we also working on the assumptions that when ISIS PDUs are send in DCs (unknown today case when out of the sudden 1000s of LSPs may need to get flooded) use of some L4 fancy flow control is an overkill and we must invent new essentially L2 flow control to cover this case to address partition repair ? 


I am not assuming that the issue is restricted to the DC. Flooding is an issue in all IS-IS networks.

1000s of LSPs can occur in any IS-IS network of significant scale.  All it takes is healing a partition and there can easily be a large number of LSPs to transmit.  The case of 1000s of LSPs is of interest because the scale magnifies the flooding problem.  If we only have one LSP that needs flooding, this entire discussion is moot.

I am assuming that we want to go faster.  That does seem to be something that we have agreement on.

I am assuming that we dont’ want to go too fast.  Overrunning the receiver is wasteful. I think we all agree on that.

I am not assuming that we have to use some ‘L4 fancy flow control’, but I am trying to get a reasonable approximation to optimal goodput, with errors being on the conservative side (i.e., not overrunning the receiver).

My understanding of control theory is pretty rudimentary, but what I do know is that it is going to be very difficult to achieve high goodput without a control loop of some flavor. I’m open to how we do this.  Henk proposed that we simply pick up TCP for this, but my concern with that is really about introducing a whole new dependency to the protocol.  That’s a lot to chew.  Do we really need it all? I hope not.  Thus, Bruno’s original suggestion sparked my interest in doing something dynamic and simple.

Tony