Re: [Lsr] Dynamic flow control for flooding

Henk Smit <henk.ietf@xs4all.nl> Thu, 25 July 2019 14:36 UTC

Return-Path: <henk.ietf@xs4all.nl>
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 2070A120319 for <lsr@ietfa.amsl.com>; Thu, 25 Jul 2019 07:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 JR2qWPLmUd2m for <lsr@ietfa.amsl.com>; Thu, 25 Jul 2019 07:36:08 -0700 (PDT)
Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386D01202F2 for <lsr@ietf.org>; Thu, 25 Jul 2019 07:36:08 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:207]) by smtp-cloud8.xs4all.net with ESMTPA id qeqihB1lAeD5bqeqihiIQl; Thu, 25 Jul 2019 16:36:05 +0200
Received: from knint.xs4all.nl ([83.163.74.169]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 25 Jul 2019 16:36:04 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 25 Jul 2019 16:36:04 +0200
From: Henk Smit <henk.ietf@xs4all.nl>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: stephane.litkowski@orange.com, Tony Li <tony.li@tony.li>, lsr@ietf.org
In-Reply-To: <BYAPR11MB36388446EBAF9B7DDE2F2765C1C60@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <CAMj-N0LdaNBapVNisWs6cbH6RsHiXd-EMg6vRvO_U+UQsYVvXw@mail.gmail.com> <BYAPR11MB36382C89363202D1B5659614C1C70@BYAPR11MB3638.namprd11.prod.outlook.com> <5841_1563943794_5D37E372_5841_105_1_9E32478DFA9976438E7A22F69B08FF924D9C373E@OPEXCAUBMA3.corporate.adroot.infra.ftgroup> <BYAPR11MB363856BB026992DFBB3BB224C1C60@BYAPR11MB3638.namprd11.prod.outlook.com> <8376a87831ffa6f5298c5122907c6e66@xs4all.nl> <BYAPR11MB36388446EBAF9B7DDE2F2765C1C60@BYAPR11MB3638.namprd11.prod.outlook.com>
Message-ID: <8e7a34477feac00afefbb7d5a5fe78f7@xs4all.nl>
X-Sender: henk.ietf@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfG2LdhywReCw9u79MhcEEWuRCaSPUslFT2fZJHCqeaTgMkk96THWrE/MBSY+5zLZAwfmF5ObUIKOF1NyKOMGLd1VTqANwkvyWlV4jcopZ+BIAHngK7To xQK7gTSneZ7SLrpCr1LW13RKRMGtZ6Yc0bMDB8goRt/a/p0q4CGQkhcloMhSfBKaJMaPu7WbE7+zEEebl5aOws1hdgUdQcAZWYBJT+Nm4PXwNMS02xovmaxb hEEZCeTuYzg8kFNGBDzHs0T1yQ2iMrNnTaNS80k3yeK7Tary+/jCm6AqgXVlqa1KwOE8pYh2zjBpJ2NMdqVBIg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/v-ILvF1X8bUY2Yt2V3w_w0Gphgk>
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: Thu, 25 Jul 2019 14:36:15 -0000

Hello Les,

Thanks for taking the time to respond.

> [Les:] Base specification defines partialSNPInterval (2 seconds).
> Clearly w faster flooding we should look at decreasing this
> timer - but we certainly should not do away with it.

That was the point I was trying to make:
You kept mentioning that your "tx based flow control" only needed
changes to the internal implementation of the LSP-sender.
That's not the case. Your algorithm also depends on behaviour
of the LSP-receiver. I did not see that mentioned anywhere before.
Good to see that you (and Tony) now acknowledge this necessity.

I hope you also realize (and agree) that changing the algorithm
to send PSNPs on the LSP-receiver, in a way to improve the
flow-control algorithm for the LSP-sender, will probably have a
negative impact on the current efficiency of bundling acks in
PSNPs. And that change can multiply the number of PSNPs (and thus
ISIS PDUs in input queues) that need to be received on routers.

> If you don’t like the name we can certainly find something more 
> appealing.

I don't care much about the name.
(In general I do care about naming in programming. And even 10x more 
about
naming in protocol documents. But that's not important in the discussion
at the moment).

The point I was trying to get across is that your proposal is not
something that happens internally on a single individual router. It is
an algorithm that involves 2 routers. And thus it is a protocol issue.

> What I am proposing does not require protocol extensions -
> therefore no draft is required.

Protocols do no only describe octets on the wire. They also describe
behaviour. Thus, as Tony has already said, your proposed algorithm
also need to be documented. In an RFC probably.

> Whether a BCP draft is desired is something I am open to considering.

I don't know much about process in the IETF. But I was always under
the assumptions that BCPs were mostly network design/configuration
recommendations for network operators.


 From an earlier email:
> [Les:] I think you know what I am about to say.. :)

Yes, my question of why use exponential backoffs was a rethorical
question (as I wrote at the end of my email).
I wrote:
>> I hope it is clear to everyone that these are not serious questions. 
>> I'm
>> just saying: "sometimes fast is slow".

FYI, few people probably know this, but I happen to be the guy that
intially came up with the idea of exponential backoffs in IGPs.
(Back in 1999 when I was at cisco).

Anyway, to reiterate my point: "sometimes fast is slow". It seems we
now all agree that sending LSPs "rapidly" and then assuming 
retransmissions
will fix any problems, is an approach that is way too naive. Good.

henk.