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

Peter Psenak <ppsenak@cisco.com> Thu, 23 April 2020 09:14 UTC

Return-Path: <ppsenak@cisco.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 4EEB13A176F for <lsr@ietfa.amsl.com>; Thu, 23 Apr 2020 02:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 eVLuRjDZkUAB for <lsr@ietfa.amsl.com>; Thu, 23 Apr 2020 02:14:28 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8D23A176B for <lsr@ietf.org>; Thu, 23 Apr 2020 02:14:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17105; q=dns/txt; s=iport; t=1587633268; x=1588842868; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oRyg0S0RvSM9ZQdjVOyHNcyIGBF1YbE7pMEkML7CVpU=; b=muDnaRC9c3g0YTVEElBzvit4b6oI7a+S6onrm1LTey0UAm3cR0kd7+yo QoSky35s30JuvDaVb46Cvdt20q0gCqxKSa+nr1hQoNU9PU1y89/hBxoJK KB2GyVJ1T/NBU32wGwYlusMGC+t8Orb5KEDGQGFDb7ESUnIMubFBqGqI/ 4=;
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="25516235"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Apr 2020 09:14:26 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 03N9EPDC012308; Thu, 23 Apr 2020 09:14:26 GMT
To: bruno.decraene@orange.com, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
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> <19183_1587578655_5EA0871F_19183_421_1_53C29892C857584299CBF5D05346208A48E26EA9@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <34a1bd49-417e-af46-758e-24663b77f813@cisco.com> <32451_1587632254_5EA1587E_32451_425_20_53C29892C857584299CBF5D05346208A48E27C99@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <bdf4b5a4-36f1-d018-a684-f4a5cbd3903c@cisco.com>
Date: Thu, 23 Apr 2020 11:14:25 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <32451_1587632254_5EA1587E_32451_425_20_53C29892C857584299CBF5D05346208A48E27C99@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_ya5vhIo9Xak-eUWapR-Oi3HXx0>
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: Thu, 23 Apr 2020 09:14:31 -0000

Bruno,

On 23/04/2020 10:57, bruno.decraene@orange.com wrote:
> Peter,
>   
>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>
>> Bruno,
>>
>> On 22/04/2020 20:04, bruno.decraene@orange.com wrote:
>>> Les,
>>>
>>> Pleasesee inline
>>>
>>> *From:*Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
>>> *Sent:* Tuesday, April 21, 2020 11:48 PM
>>> *To:* DECRAENE Bruno TGI/OLN
>>> *Cc:* lsr@ietf.org
>>> *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed
>>>
>>> Bruno –
>>>
>>> You have made an assumption that historically vendors have tuned LSP
>>> transmission rates to a platform specific value.
>>>
>>> [Bruno] I don’t think so. What makes you think so?
>>>
>>> In all cases, that is not my assumption, and for multiple reasons.
>>>
>>> That certainly is not true in the case of my employer (happy to hear
>>> what other vendors have been doing for the past 20 years).
>>>
>>> The default value is based on minimumBroadcastLSPTransmissionInterval
>>> specified in ISO10589.
>>>
>>> A knob is available to allow tuning (faster or slower) in a given
>>> deployment – though in my experience this knob is rarely used.
>>>
>>> *//*[Bruno] I would agree on both. More interestingly is the why: why
>>> aren’t those existing sending parameters tuned, while we agree that
>>> default configuration are suboptimal?
>>>
>>> My take is that:
>>>
>>> -We don’t want to overload the receiver and create loss of LSP (as this
>>> will delay the LSDB synchronization and decrease the goodput). Hence
>>> this (the parameters) is receiver dependent (e.g., platform type, number
>>> of IGP adjacencies, …).
>>>
>>> -We don’t know which value to configure : difficult for the network
>>> operator to evaluate without a significant knowledge of the receiver
>>> implementation (in particular QoS parameters for incoming LSP), vendors
>>> are not really proposing value or guidance, especially since the sending
>>> behavior is not standardized and slightly different between vendors. So
>>> everyone stay safe with default 20 years old values.
>>>
>>> We already discuss in
>>> https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2
>>> that this common interpretation isn’t the most appropriate, but
>>> historically the concern has been to avoid flooding too fast – not to
>>> optimize flooding speed.
>>>
>>> Obviously, we are revisiting that approach and saying it needs to change
>>> – which is something I think we have consensus on.
>>>
>>> I have provided a description in my recent response as to why it is
>>> difficult to derive an optimal value on a per platform basis. You may
>>> disagree – but please do not claim that we actually have been doing this
>>> for years. We haven’t been.
>>>
>>> *//*[Bruno] I’m not sure how to rephrase my below email so that we could
>>> understand each other, have an answer from your side (I mean employer
>>> side), and progress.
>>>
>>> More succinctly: How do network operator correctly configure the
>>> flooding parameters value on the implementation of your employer? In
>>> particular given the variety of conditions on the LSP receiver side.
>>
>> the answer is test and see which value fits best in your specific
>> environment.
> 
> I don't think that's good enough, or even feasible given the very diverse set of platforms and environments in large networks, and/or the availability of human resources in smaller networks.
> Since Les is reporting that virtually nobody is changing the default value -although we now all agree that they are suboptimal- I think that this is an indication that this strategy is not working.
> That's why I brought this to the LSR WG.

we agree on the problem and the solution, for most part anyway.

I responded with the only option that is available today with existing 
protocol behavior and parameters available today.

thanks,
Peter



> 
> We need the IS-IS protocol to work adequately without requiring constant or personalized tuning from the network operator. Coming back to TCP, general user/terminals are not been asked to run test per terminal and per destination/server. It just work relatively adequately.
>   
>> One reason to have some sort of feedback mechanism (being it tx or rx
>> based) is to avoid the need to tune today's static parameters and flood
>> as fast as the receiver is able to consume and slow down if the receiver
>> is not able to cope with the rate we flood.
> 
> +1
>   
> Thanks,
> Bruno
> 
>> thanks,
>> Peter
>>
>>
>>
>>
>>
>>
>>>
>>> --Bruno
>>>
>>>     Les
>>>
>>> *From:*bruno.decraene@orange.com <bruno.decraene@orange.com>
>>> *Sent:* Monday, April 20, 2020 4:47 AM
>>> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
>>> *Cc:* lsr@ietf.org
>>> *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed
>>>
>>> Les,
>>>
>>> After nearly 2 months, can we expect an answer from your side?
>>>
>>> More specifically, the below question
>>>
>>> [Bruno] _Assuming_ that the parameters are static, the parameters
>>> proposed in draft-decraene-lsr-isis-flooding-speed are the same as the
>>> one implemented (configured) on multiple implementations, including the
>>> one from your employer.
>>>
>>> Now do you believe that those parameters can be determined?
>>>
>>> §  If yes, how do you do _today_ on your implementation? (this seems to
>>> contradict your statement that you have no way to figure out how to find
>>> the right value)
>>>
>>> §  If no, why did you implement those parameters, and ask network
>>> operator to configure them?
>>>
>>> Thank you,
>>>
>>> --Bruno
>>>
>>> *From:*DECRAENE Bruno TGI/OLN
>>> *Sent:* Wednesday, February 26, 2020 8:03 PM
>>> *To:* 'Les Ginsberg (ginsberg)'
>>> *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>
>>> *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed
>>>
>>> Les,
>>>
>>> Please see inline[Bruno]
>>>
>>> *From:*Lsr [mailto:lsr-bounces@ietf.org] *On Behalf Of *Les Ginsberg
>>> (ginsberg)
>>> *Sent:* Wednesday, February 19, 2020 3:32 AM
>>> *To:* lsr@ietf.org <mailto:lsr@ietf.org>
>>> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>>>
>>> Base protocol operation of the Update process tracks the flooding of
>>>
>>> LSPs/interface and guarantees timer-based retransmission on P2P interfaces
>>>
>>> until an acknowledgment is received.
>>>
>>> Using this base protocol mechanism in combination with exponential
>>> backoff of the
>>>
>>> retransmission timer provides flow control in the event of temporary
>>> overload
>>>
>>> of the receiver.
>>>
>>> This mechanism works without protocol extensions, is dynamic, operates
>>>
>>> independent of the reason for delayed acknowledgment (dropped packets, CPU
>>>
>>> overload), and does not require additional signaling during the overloaded
>>>
>>> period.
>>>
>>> This is consistent with the recommendations in RFC 4222 (OSPF).
>>>
>>> Receiver-based flow control (as proposed in
>>> https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ )
>>>
>>> requires protocol extensions and introduces additional signaling during
>>>
>>> periods of high load. The asserted reason for this is to optimize
>>> throughput -
>>>
>>> but there is no evidence that it will achieve this goal.
>>>
>>> Mention has been made to TCP-like flow control mechanisms as a model - which
>>>
>>> are indeed receiver based. However, there are significant differences
>>> between
>>>
>>> TCP sessions and IGP flooding.
>>>
>>> TCP consists of a single session between two endpoints. Resources
>>>
>>> (primarily buffer space) for this session are typically allocated in the
>>>
>>> control plane and current usage is easily measurable..
>>>
>>> IGP flooding is point-to-multi-point, resources to support IGP flooding
>>>
>>> involve both control plane queues and dataplane queues, both of which are
>>>
>>> typically not per interface - nor even dedicated to a particular protocol
>>>
>>> instance. What input is required to optimize receiver-based flow control
>>> is not fully specified.
>>>
>>> https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
>>> suggests (Section 5) that the values
>>>
>>> to be advertised:
>>>
>>> "use a formula based on an off line tests of
>>>
>>>      the overall LSPDU processing speed for a particular set of hardware
>>>
>>>      and the number of interfaces configured for IS-IS"
>>>
>>> implying that the advertised value is intentionally not dynamic. As such,
>>>
>>> it could just as easily be configured on the transmit side and not require
>>>
>>> additional signaling. As a static value, it would necessarily be somewhat
>>>
>>> conservative as it has to account for the worst case under the current
>>>
>>> configuration - which means it needs to consider concurrent use of the CPU
>>>
>>> and dataplane by all protocols/features which are enabled on a router -
>>> not all of whose
>>>
>>> use is likely to be synchronized with peak IS-IS flooding load.
>>>
>>> [Bruno] _/Assuming/_ that the parameters are static, those parameters
>>>
>>> oare the same as the one implemented (configured) on multiple
>>> implementations, including the one from your employer. Now do you
>>> believe that those parameters can be determined?
>>>
>>> §If yes, how do you do _/today/_ on your implementation? (this seems to
>>> contradict your statement that you have no way to figure out how to find
>>> the right value)
>>>
>>> §If no, why did you implement those parameters, and ask network operator
>>> to configure them?
>>>
>>> §There is also the option to reply: I don’t know but don’t care as I
>>> leave the issue to the network operator.
>>>
>>> ocan still provide some form of dynamicity, by using the PSNP as dynamic
>>> acknowledgement.
>>>
>>> oare really dependent on the receiver, not the sender.
>>>
>>> §the sender will never overload itself.
>>>
>>> §The receiver has more information,  knowing its processing power (low
>>> end, high end, 80s, 20s (currently we are stuck with 20 years old value
>>> assuming the worst possible receiver (and worst there were, including
>>> with packet processing partly done in the control plane processor)), its
>>> expected IS-IS load (#neighbors), its preference for bursty LSP
>>> reception (high delay between IS-IS CPU allocation cycles, memory not an
>>> issue up to x kilo-octet…), its expected control plane load if IS-IS
>>> traffic has not higher priority over other control plane traffic…), it’s
>>> expected level of QoS prioritization [1]
>>>
>>> · [1] looks for “Extended SPD Headroom”. E.g. “Since IGP and link
>>> stability are more tenuous and more crucial than BGP stability, such
>>> packets are now given the highest priority and are given extended SPD
>>> headroom with a default of 10 packets. This means that these packets are
>>> not dropped if the size of the input hold queue is lower than 185 (input
>>> queue default size + spd headroom size + spd extended headroom).”
>>>
>>> oAnd this is for distributed architecture, 15 years ago. So what about
>>> using the above number (in the router configuration), applies Tony’s
>>> proposal (*oversubscription/number of IS neighbhors), and advertise this
>>> value to your LSP sender?
>>>
>>> [1]
>>> https://www.cisco.com/c/en/us/support/docs/routers/12000-series-routers/29920-spd.html
>>>
>>>
>>> -
>>>
>>> --Bruno
>>>
>>> Unless a good case can be made as to why transmit-based flow control is
>>> not a good
>>>
>>> fit and why receiver-based flow control is demonstrably better, it seems
>>>
>>> unnecessary to extend the protocol.
>>>
>>>       Les
>>>
>>> *From:*Lsr <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf..org>> *On
>>> Behalf Of *Les Ginsberg (ginsberg)
>>> *Sent:* Tuesday, February 18, 2020 6:25 PM
>>> *To:* lsr@ietf.org <mailto:lsr@ietf.org>
>>> *Subject:* [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>>>
>>> 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.
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc
>>>
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>> recu ce message par erreur, veuillez le signaler
>>>
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>>> electroniques etant susceptibles d'alteration,
>>>
>>> Orange decline toute responsabilite si ce message a ete altere, deforme
>>> ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged
>>> information that may be protected by law;
>>>
>>> they should not be distributed, used or copied without authorisation.
>>>
>>> If you have received this email in error, please notify the sender and
>>> delete this message and its attachments.
>>>
>>> As emails may be altered, Orange is not liable for messages that have
>>> been modified, changed or falsified.
>>>
>>> Thank you.
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>> Thank you.
>>>
>>
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> 
>