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

Robert Raszuk <robert@raszuk.net> Wed, 19 February 2020 18:55 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 0BE55120111 for <lsr@ietfa.amsl.com>; Wed, 19 Feb 2020 10:55: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 r-sgLmbf-5FR for <lsr@ietfa.amsl.com>; Wed, 19 Feb 2020 10:55:18 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 E9AA4120072 for <lsr@ietf.org>; Wed, 19 Feb 2020 10:55:17 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id a142so24848377oii.7 for <lsr@ietf.org>; Wed, 19 Feb 2020 10:55:17 -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=YqcAwlJA7CQ5MH3aVy7YWzo5mDxdrDd0MUX3bVmlgG4=; b=HR36F54vsakvnZhfpinu18i7PYZtEfhXeDpF432xkMbC7/LoNaW9TvqFvPcZvidaBS Ze1YVyMWa93Jv/kxvw2Tonw2V4cK9hGLyFSm9nVB2hybjpVDgoZ+2ADpXdi39/dHr1Uc klFRHMW92UYOf6ozA/UlMP0Q34n3necPlDY4r3BA7cWVcOKwB/04gIe0JsaBTbsOYggk nSllnfoMNV9XzcLjkuELFFfEOCRcWgYOMs1UHL2/TnvBpX5vLwR4ROVprUaKUs5vTdvY 0Ucva3njJIsxK5ydtBVb5jawtmmie+78H6KZpPD/T9wUxUiWWHuk0Dc0KHfWDmMpVKgG IF9g==
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=YqcAwlJA7CQ5MH3aVy7YWzo5mDxdrDd0MUX3bVmlgG4=; b=grk+vXM5/Ds5VxxBNodyEX/LmFDaSZFoY9zeK0FYeMyXghGMQDvPrULW1Dm5AtO33s 5hiyl8Mxe3hg6fKrLKLP66386Bu6kfPOx6TcMT4BCzdXwd9lsV+1uLgg1Sro9ZBk92ld /9yZsKmsn1507aoznRW5JF5mH5ayD9dgUybrZiR9i/tMowbQnhzbl7HV/xIP9eWcvxrE m0V39Le3PIF5XS5/58f9fK6zxBAJDahmjo2tHXHV8giD9a0eiBjk7fBG89zzr+0DAN+y a1wKH0ByDRJkJzMdljEFqO8BLM/2qHf8ULljAWdKqbn2Q5vvB4H14dU5Ldi4wA3RdzH3 zx0w==
X-Gm-Message-State: APjAAAVI0nIPtFRKAnfEUL/xgOXJETUKOBarnozFENfXifK9v+u3OlH6 w1TjyUrbCCt83TTwEgVAVbcSmwgNL7oq2Af8vLTv539P
X-Google-Smtp-Source: APXvYqyaE7wGp3mA/vlZISG9S5VYlCpNKBE85JpTwyc10nWzdKH8orkE2JOLOG7bva7gzSjc9Ni8+QAkBpW68JgI+QU=
X-Received: by 2002:aca:d985:: with SMTP id q127mr5342344oig.132.1582138517072; Wed, 19 Feb 2020 10:55:17 -0800 (PST)
MIME-Version: 1.0
References: <MW3PR11MB46191E81D5B22B454D8184A4C1100@MW3PR11MB4619.namprd11.prod.outlook.com> <CAOj+MMEkQRArOZJc_Fhc0PqKT9xSRjqSBj+h0mBtj78W7niuSg@mail.gmail.com> <MW3PR11MB4619E47034C379FB48208C9AC1100@MW3PR11MB4619.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB4619E47034C379FB48208C9AC1100@MW3PR11MB4619.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 19 Feb 2020 19:55:07 +0100
Message-ID: <CAOj+MMHw1ePUmdcYanOcv9kC6KbtRSu6-Varuhi+0GMM7cyfQg@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004bc2c2059ef254c3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/3k66WMrTToIsveN_milIjXUt4rE>
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 18:55:20 -0000

Hi Les,

Yes this "small delay" of ACK aggregation is something which I am a bit
worried here from SNPs sender side.

Now as indeed draft mentioned prioritizing SNPs on reception let me
indicate that some platforms I have not so long ago dealt with do not even
prioritize any IGP packet over other packets at neither ingress LC nor
queue to RE/RP. If that channel takes 100s of ms within the box I am
afraid all bets for flooding improvement are off.

Thx
R,.


On Wed, Feb 19, 2020 at 6:48 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> Robert –
>
>
>
> Thanx for your input.
>
>
>
> Note that one of the suggestions in
> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/
>  is to prioritize the reception of SNPs over LSPs so that we are less
> likely to drop ACKs.
>
> It is not clear to me why you think SNP generation would be an issue.
>
> Once a received LSP is processed one of the outputs is to set a per
> interface flag indicating that an ACK (PSNP) needs to be sent (SSN flag).
> Implementations usually implement some small delay so that multiple ACKs
> can be sent in a single PSNP – but I do not see why this should be viewed
> as a bottleneck.
>
>
>
> If your concern is that we need to emphasize the importance of sending
> timely ACKs, I think we could look at text that makes that point.
>
>
>
>    Les
>
>
>
>
>
> *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, February 19, 2020 1:07 AM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> 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.
>
>