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

Robert Raszuk <robert@raszuk.net> Wed, 19 February 2020 09:07 UTC

Return-Path: <robert@raszuk.net>
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 B84E2120024 for <lsr@ietfa.amsl.com>; Wed, 19 Feb 2020 01:07:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 TJNmXYQgy327 for <lsr@ietfa.amsl.com>; Wed, 19 Feb 2020 01:07:18 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 5664412001A for <lsr@ietf.org>; Wed, 19 Feb 2020 01:07:18 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id 66so22429274otd.9 for <lsr@ietf.org>; Wed, 19 Feb 2020 01:07:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3CyhlJvCal6YVKly/fXl3ejuVpmuIQdN3GK/e8Q4sK0=; b=D6kSWSf4nw6/JnJjliflb+dFF54LphjVWJGOKuE/QUubjJDK2Z9Eb69bMhoH2TOG5s C8H3tSjJmpd1pRI9pvYBAxx5N3KFnU1Q0g29bZXmlxSuv8WFOfsqAiWuT+Eu0Pqw0YWK 6GAWUrDpGlwt0Mjyo33+cpMxe5ZhwiWg+2Ge9hF571i8e+9/0TkRhfm90HnDDBlrGmGu OtlqZ85FdfCzk2vDMkGG3j+J0CfO0G0MmecBhOrQAA8x+p3ax24L5nMWnci1Mglno63y dP5MDEg/u6uu3rEUeJDbxTALYp/DZDBh9ruE0bnCKTz4BGKownL8RMZcG0pYRSm6aIxE 7VWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3CyhlJvCal6YVKly/fXl3ejuVpmuIQdN3GK/e8Q4sK0=; b=j3VFNoEQOoUrkWEnWcQU1V6NOn9wFfUfrSSkmoqTMO0BUCaPs/lyqGCCyKRtGaaWdB N1bCYVFfl2YNfP3R+p7nuDd5DbP6z8LB+stKfKlaIASlieVDNWOrYAzxZBxqVn3aXbhR BiOnvzhbFzq+lcHftusGaq74xY52ZuAb8yPTW+gx0pBrUpFLWd1d8gcDKxAmMLptujcw 9FtyIpbbzFOux3kJtqUZHCtzMIYfM9UFW1FwJccj0LMoFOMyCMnvPDJ8sugDvNkcq+f/ gUaHYr4nZfUNPanQ5kJBaz8vbCFdNcbPoVLFn6HCogfzsar5eakXtov0kbaQmRTY1keT Q09Q==
X-Gm-Message-State: APjAAAWL65rosMRKbvgQo7skxdKdGGVAuFIAgmv017FIbvr0kAYZ/ZsX ssadRfrdx1id+5xj/HIRHWNhVuBXAUUC0BRZDlmEfg==
X-Google-Smtp-Source: APXvYqzW3koyZOAyjTNUMzyypoEGR51uwAV+w13kEdmaYCAorpFSEoGX9ft2iZ1ZtXd3Z0warI7fBZsHfmOOpiEEs1g=
X-Received: by 2002:a05:6830:1385:: with SMTP id d5mr19575261otq.61.1582103237489; Wed, 19 Feb 2020 01:07:17 -0800 (PST)
MIME-Version: 1.0
References: <MW3PR11MB46191E81D5B22B454D8184A4C1100@MW3PR11MB4619.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB46191E81D5B22B454D8184A4C1100@MW3PR11MB4619.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 19 Feb 2020 10:07:08 +0100
Message-ID: <CAOj+MMEkQRArOZJc_Fhc0PqKT9xSRjqSBj+h0mBtj78W7niuSg@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000780f75059eea1d2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/gSvOCfRxHNQbtJKkGirtpUc5kyY>
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 09:07:21 -0000

Hi Les & all,

Watching this discussion I would like to state that IMO going with
transmitter based rate limiting (I would not call it flow control) is much
easier option to deploy and operate. It also has no dependency across other
side of p2p adj which is a very important factor. The only issue here is if
generation of [P|C]SNPs is fast enough.

Receiver based flow control is simple in flow theory however I have a
feeling that if we are to go that path we would be much better to actually
run ISIS flooding over DC-TCP and avoid reinventing the wheel.

Thx,
Robert.

On Wed, Feb 19, 2020 at 3:26 AM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> Two recent drafts advocate for the use of faster LSP flooding speeds in
> IS-IS:
>
>
>
> https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
>
> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/
>
>
>
> There is strong agreement on two key points:
>
>
>
> 1)Modern networks require much faster flooding speeds than are commonly in
> use today
>
>
>
> 2)To deploy faster flooding speeds safely some form of flow control is
> needed
>
>
>
> The key point of contention between the two drafts is how flow control
> should be implemented.
>
>
>
> https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
> advocates for a receiver based flow control where the receiver advertises
> in hellos the parameters which indicate the rate/burst size which the
> receiver is capable of supporting on the interface. Senders are required to
> limit the rate of LSP transmission on that interface in accordance with the
> values advertised by the receiver.
>
>
>
> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/
>  advocates for a transmit based flow control where the transmitter monitors
> the number of unacknowledged LSPs sent on each interface and implements a
> backoff algorithm to slow the rate of sending LSPs based on the length of
> the per interface unacknowledged queue.
>
>
>
> While other differences between the two drafts exist, it is fair to say
> that if agreement could be reached on the form of flow control  then it is
> likely other issues could be resolved easily.
>
>
>
> This email starts the discussion regarding the flow control issue.
>
>
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>