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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Feb 2020 02:25:27 +0000

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Feb 2020 02:31:59 +0000

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.
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 <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, February 18, 2020 6:25 PM
To: [email-masked]
Subject: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Feb 2020 14:09:42 +1100

> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/ <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.

Les,

This makes the assumption that there is a per-interface queue on the LSP receiver. That has never been the case on any implementation that I’ve ever seen.

Without this assumption or more information, it seems difficult for the LSP transmitter to have enough information about how to proceed.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Feb 2020 06:05:16 +0000

Tony –

There is no such assumption.

Transmitter has exact knowledge of how many unacknowledged LSPs have been transmitted on each interface.

Using an algorithm functionally equivalent to the example algorithm in the draft, the transmitter slows down when the neighbor is not acknowledging in a timely manner LSPs sent on that interface.
The reason the neighbor is falling behind is irrelevant.

Maybe the receiver has a per interface queue and the associated line card is overloaded.
Maybe the receiver has a single queue but there are so many LSPs received on other interfaces in the front of the queue that the receiver hasn’t yet processed the ones received on this interface.
Maybe the receiver received the same LSPs on other interfaces and is now so busy sending these LSPs that it has fallen behind on processing its receive queue.
Maybe BGP is consuming high CPU and starving IS-IS…

The transmitter doesn’t care.  It just adjusts the transmission rate based on actual performance.

If all interfaces on the receiver are backed up all the neighbors will slow down their transmission rate.

The TX side flow control is purely based on performance on each interface – there are no implementation requirements imposed or implied as regards the receiver.

    Les

From: Tony Li <[email-masked]>
Sent: Tuesday, February 18, 2020 7:10 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Les,

Tony

---

From: [email-masked]
Date: Wed, 19 Feb 2020 17:15:30 +1100

> The TX side flow control is purely based on performance on each interface – there are no implementation requirements imposed or implied as regards the receiver.

Then the LSP transmitter is operating without information from the LSP receiver. Additional information from the receiver can help the transmitter maintain a more accurate picture of reality and adapt to it more quickly.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Feb 2020 06:32:01 +0000

Tony -

From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, February 18, 2020 10:16 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Les:] This is your claim – but you have not provided any specifics as to how information sent by the receiver would provide better adaptability than a Tx based flow control which is based on actual performance.
Nor have you addressed how the receiver would dynamically calculate the values it would send. For me how to do this is not at all obvious given common implementation issues such as:

  *   Sharing of a single punt path queue among many incoming protocols/incoming interfaces
  *   Single interface independent input queue to IS-IS itself, making it difficult to track the contribution of a single interface to the current backlog
  *   Distributed dataplanes

If we are to introduce new signaling/protocol extensions there needs to be good reason and it must be practical to implement – especially since we have an alternate solution which is practical to implement, dynamically responds to current state, and does not require any protocol extensions.

    Les

---

From: [email-masked]
Date: Wed, 19 Feb 2020 17:42:31 +1100

Les,

> [Les:] This is your claim – but you have not provided any specifics as to how information sent by the receiver would provide better adaptability than a Tx based flow control which is based on actua…

This is not a claim. This is normally how control loops work. See TCP. When the receiver’s window opens, it can tell the transmitter. When the receiver’s window closes, it can tell the transmitter. If it only opens a little bit, it can tell the transmitter.

> Nor have you addressed how the receiver would dynamically calculate the values it would send.

It can look at its input queue and report the current space.  ~”Hi, I’ve got buffers available for 20 packets, totalling 20kB.”~  

> For me how to do this is not at all obvious given common implementation issues such as:
>  
> Sharing of a single punt path queue among many incoming protocols/incoming interfaces

The receiver gets to decide how much window it wants to provide to each transmitter. Some oversubscription is probably a good thing.

> Single interface independent input queue to IS-IS itself, making it difficult to track the contribution of a single interface to the current backlog

It’s not clear that this is problematic.  Again, reporting the window size in this queue is helpful.

> Distributed dataplanes

This should definitely be a non-issue. An implementation should know the data path from the interface to the IS-IS process, for all data planes involved, and measure accordingly.

> If we are to introduce new signaling/protocol extensions there needs to be good reason and it must be practical to implement – especially since we have an alternate solution which is practical to i…

If we are to introduce new behaviors, they must be helpful. Estimates that do not utilize the available information may be sufficiently erroneous as to be harmful (see silly window syndrome).

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Feb 2020 07:19:08 +0000

Tony –

Overall, I think you are making  general statements and not providing needed specifics.
Maybe it’s obvious to you how a receiver based window would be calculated – but it isn’t obvious to me – so please help me out here with specifics.
What inputs do you need on the receive side in order to do the necessary calculation?
What assumptions are you making about how an implementation receives, punts, dequeues IS-IS LSPs?
And how will this lead to better performance than having TX react to actual throughput?

And please do not say  “just like TCP”. I have made some specific statements about how managing the resources associated with a TCP connection is not at all similar to managing resources for IGP flooding.
If you disagree – please provide some specific explanations.

A few more comments inline – but rather than go back-and-forth on each line item, it would be far better if you wrote up the details of the RX side solution.
Thanx.

From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, February 18, 2020 10:43 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Les,

[Les2:] TCP != IGP flooding – please see my remarks in my initial posting on this thread.

[Les2:] None of the implementations I have worked on (at least 3) work this way.

The receiver gets to decide how much window it wants to provide to each transmitter. Some oversubscription is probably a good thing.
[Les2:] That wasn’t my point. Neither of us Is advocating trying to completely eliminate retransmissions and/or transient overload.
And since drops are possible, looking at the length of an input queue isn’t necessarily going to tell you whether you are indeed overloaded and if so due to what interface(s).
Tx side flow control is agnostic to receiver implementation strategy and the reasons why LSPs remain unacknowledged..

[Les2:] Sorry, this is exactly the sort of generic statement that doesn’t add much. I know you believe this, but you need to explain how this is better than simply looking at what remains unacknowledged.

  *   Distributed dataplanes

[Les2:] Again, you provide no specifics. Measure “what” accordingly? IF I do not have a queue dedicated solely to IS-IS packets to be punted (and implementations may well use a single queue for multiple protocols) what should I measure? How to get that info to the control plane in real time?

[Les2:] Again – you try to apply TCP heuristics to IGP flooding. Not at all intuitive to me that this applies – I have stated why.

   Les

Tony

---

From: [email-masked]
Date: Wed, 19 Feb 2020 18:52:39 +1100

Les,

> Overall, I think you are making  general statements and not providing needed specifics.

I’m sorry it’s not specific enough for you.  I’m not sure that I can help to your satisfaction.

> What inputs do you need on the receive side in order to do the necessary calculation?

Well, there can be many, as it depends on the receiver’s architecture. Now, I can’t talk about things that are under NDA or company secret, so I’m pretty constrained.  Talking about any specific implementation is going to not be very helpful, so I propose that we stick with a simplified model to start: a box with N interfaces and a single input queue up to the CPU.  The input queue is the only possible bottleneck.  Further, the avoid undue complexity (for the moment — it may return), let’s assume that the input queue is in max-MTU sized packets, so that knowing the free entries in this queue is entirely sufficient.  Let the number of free entries be F.

As previously noted, we will want some oversubscription factor.  For the sake of a simple model, let’s consider this a constant and call it O.  [For future reference, I suspect that we will want to come back and make this more sophisticated, such as a Kalman filter, but again, to start simply… ]

Now, we want to report the free space devoted to the interface, but derated by the oversubscription factor, so we end up reporting F*O/N. 

Is that specific enough?

> What assumptions are you making about how an implementation receives, punts, dequeues IS-IS LSPs?

None.

> And how will this lead to better performance than having TX react to actual throughput?

The receiver will have better information. The transmitter can now convey useful things like “I processed all of your packets but my queue is still congested”, this would be a PSN that acknowledges all outstanding LSPs but shows no free buffers.

> If you disagree – please provide some specific explanations.

I disagree with your disagreement.  A control loop is a very simple primitive in control theory.  That’s what we’re trying to create.  Modulating the receive window through control feedback is a control theory 101 technique.

> [Les2:] None of the implementations I have worked on (at least 3) work this way.

Well, sorry, some of them do.  In particular the Cisco AGS+ worked exactly this way under IOS Classic in the day.  It may have morphed.

> And since drops are possible, looking at the length of an input queue isn’t necessarily going to tell you whether you are indeed overloaded and if so due to what interface(s).

Looking at the length of the input queue does give you a snapshot at your congestion level.  You are correct, it does NOT ascribe it to specific interfaces.  A more sophisticated implementation might modulate its receive window inversely proportional to its interface input rate.

> Tx side flow control is agnostic to receiver implementation strategy and the reasons why LSPs remain unacknowledged..

Yes, it’s ignorant.  That doesn’t make it better.  The point is to maximize the goodput.  Systems theory tells us that we improve frequency response when we provide feedback.  That’s all I’m suggesting.

> [Les2:] Again, you provide no specifics. Measure “what” accordingly?

The input queue size for the data path from the given interface.

> IF I do not have a queue dedicated solely to IS-IS packets to be punted (and implementations may well use a single queue for multiple protocols) what should I measure? How to get that info to the control plane in real time?

You should STILL use that queue size.  That is still the bottleneck.

You get that to the control plane by doing a PIO to the queue status register in the dataplane ASIC.  This is trivial.

> [Les2:] Again – you try to apply TCP heuristics to IGP flooding. Not at all intuitive to me that this applies – I have stated why.

Please take a class in systems theory, analog electronics, or control theory.  Just stating that it does not apply does not make it true.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Feb 2020 09:56:17 +0100

Tony,

On 19/02/2020 08:52, [email-masked] wrote:
>> Maybe it’s obvious to you how a receiver based window would be 
>> calculated – but it isn’t obvious to me – so please help me out here 
>> with specifics.
> Well, there can be many, as it depends on the receiver’s architecture. 
> Now, I can’t talk about things that are under NDA or company secret, so 
> I’m pretty constrained.  Talking about any specific implementation is 
> going to not be very helpful, so I propose that we stick with a 
> simplified model to start: a box with N interfaces and a single input 
> queue up to the CPU.  The input queue is the only possible bottleneck.

above is nowhere close to what the reality is, especially in the 
distributed system. In such system, packets traverses via multiple 
queues on both LC and RP and application like IGP has no visibility to 
these queues.

thanks,
Peter

>   Further, the avoid undue complexity (for the moment — it may return), 
> let’s assume that the input queue is in max-MTU sized packets, so that 
> knowing the free entries in this queue is entirely sufficient.  Let the 
> number of free entries be F.
> 
> As previously noted, we will want some oversubscription factor.  For the 
> sake of a simple model, let’s consider this a constant and call it O. 
>   [For future reference, I suspect that we will want to come back and 
> make this more sophisticated, such as a Kalman filter, but again, to 
> start simply… ]
> 
> Now, we want to report the free space devoted to the interface, but 
> derated by the oversubscription factor, so we end up reporting F*O/N.
> 
> Is that specific enough?
> 
> 
> The receiver will have better information. The transmitter can now 
> convey useful things like “I processed all of your packets but my queue 
> is still congested”, this would be a PSN that acknowledges all 
> outstanding LSPs but shows no free buffers.
> 
>> And please do not say  “just like TCP”. I have made some specific 
>> statements about how managing the resources associated with a TCP 
>> connection is not at all similar to managing resources for IGP flooding.
> I disagree with your disagreement.  A control loop is a very simple 
> primitive in control theory.  That’s what we’re trying to create. 
>   Modulating the receive window through control feedback is a control 
> theory 101 technique.
> 
> 
>> It can look at its input queue and report the current space.  ~”Hi, 
>> I’ve got buffers available for 20 packets, totalling 20kB.”~
>> */[Les2:] None of the implementations I have worked on (at least 3) 
>> work this way./*
> 
> 
> Well, sorry, some of them do.  In particular the Cisco AGS+ worked 
> exactly this way under IOS Classic in the day.  It may have morphed.
> 
> 
>>     */For me how to do this is not at all obvious given common
>>     implementation issues such as:/*
>>     *//*
>>
>>       * */Sharing of a single punt path queue among many incoming
>>         protocols/incoming interfaces/*
>>
>> The receiver gets to decide how much window it wants to provide to 
>> each transmitter. Some oversubscription is probably a good thing.
>> */[Les2:] That wasn’t my point. Neither of us Is advocating trying to 
>> completely eliminate retransmissions and/or transient overload./*
>> */And since drops are possible, looking at the length of an input 
>> queue isn’t necessarily going to tell you whether you are indeed 
>> overloaded and if so due to what interface(s)./*
> 
> 
> Looking at the length of the input queue does give you a snapshot at 
> your congestion level.  You are correct, it does NOT ascribe it to 
> specific interfaces.  A more sophisticated implementation might modulate 
> its receive window inversely proportional to its interface input rate.
> 
> 
>> *//*
>> */Tx side flow control is agnostic to receiver implementation strategy 
>> and the reasons why LSPs remain unacknowledged../*
> 
> 
> Yes, it’s ignorant.  That doesn’t make it better.  The point is to 
> maximize the goodput.  Systems theory tells us that we improve frequency 
> response when we provide feedback.  That’s all I’m suggesting.
> 
> 
>>       * */Distributed dataplanes/*
>>
>> This should definitely be a non-issue. An implementation should know 
>> the data path from the interface to the IS-IS process, for all data 
>> planes involved, and measure accordingly.
>> */[Les2:] Again, you provide no specifics. Measure “what” accordingly?/*
> 
> 
>> */IF I do not have a queue dedicated solely to IS-IS packets to be 
>> punted (and implementations may well use a single queue for multiple 
>> protocols) what should I measure? How to get that info to the control 
>> plane in real time?/*
> 
> 
> You get that to the control plane by doing a PIO to the queue status 
> register in the dataplane ASIC.  This is trivial.
> 
> 
>>     If we are to introduce new behaviors, they must be helpful.
>>     Estimates that do not utilize the available information may be
>>     sufficiently erroneous as to be harmful (see silly window syndrome).
>>
>> */[Les2:] Again – you try to apply TCP heuristics to IGP flooding. Not 
>> at all intuitive to me that this applies – I have stated why./*
>> *//*
> 
> 
> Please take a class in systems theory, analog electronics, or control 
> theory.  Just stating that it does not apply does not make it true.
> 
> Tony
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Feb 2020 10:07:08 +0100

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) <[email-masked]>
wrote:

> 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.
>
>
>
>  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.
>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Feb 2020 20:30:04 +1100

Peter,

> above is nowhere close to what the reality is, especially in the distributed system. In such system, packets traverses via multiple queues on both LC and RP and application like IGP has no visibility to these queues.

As you may recall, I was lead software architect for NCS 6000.  I am well aware that a distributed implementation is more complex.  However, Les is insistent that we discuss specifics and that is most easily done with a simpler model.

The applications can get visibility into the queues through the same fundamental mechanism: poll the various NPUs on the data path and report to the application CPU.  

Tony

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Feb 2020 10:44:03 +0100

Tony,

On 19/02/2020 10:30, Tony Li wrote:
> As you may recall, I was lead software architect for NCS 6000.  

I do recall :)

>I am well aware that a distributed implementation is more complex.  However, Les is insistent that we discuss specifics and that is most easily >done with a simpler model.
> 
> The applications can get visibility into the queues through the same fundamental mechanism: poll the various NPUs on the data path and report to >the application CPU.

everything is possible...

Given many different hardware architectures one may run a single IGP 
implementation on, this becomes impractical and complex as each hardware 
architecture has its own specifics. One would rather keep the IGP 
implementation hardware agnostic, rather than providing hardware 
specific hooks for each platform it runs on.

thanks,
Peter

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Feb 2020 20:47:11 +1100

Peter,

> Given many different hardware architectures one may run a single IGP implementation on, this becomes impractical and complex as each hardware architecture has its own specifics. One would rather keep the IGP implementation hardware agnostic, rather than providing hardware specific hooks for each platform it runs on.

This is why your software architecture has a Platform Dependent component. This is a service that you should require from the PD layer.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Feb 2020 11:09:04 +0100

Tony,

> This is why your software architecture has a Platform Dependent component. This is a service that you should require from the PD layer.

I'm aware of the PD layer and that is not the issue. The problem is that 
there is no common value to report across different PD layers, as each 
architecture may have different number of queues involved, etc. Trying 
to find a common value to report to IPGs across various PDs would 
involve some PD specific logic and that is the part I'm referring to and 
I would like NOT to get into.

thanks,
Peter

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Feb 2020 21:37:45 +1100

Peter,

> I'm aware of the PD layer and that is not the issue. The problem is that there is no common value to report across different PD layers, as each architecture may have different number of queues involved, etc. Trying to find a common value to report to IPGs across various PDs would involve some PD specific logic and that is the part I'm referring to and I would like NOT to get into.

I’m sorry that scares you.  It would seem like an initial implementation might be to take the min of the free space of the queues leading from the interface to the CPU. I grant you that some additional sophistication may be necessary, but I suspect that this is not going to become more complicated than polynomial evaluation. 

Tony

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Feb 2020 11:49:20 +0100

Tony,

On 19/02/2020 11:37, Tony Li wrote:
> I’m sorry that scares you.  It would seem like an initial implementation might be to take the min of the free space of the queues leading from the >interface to the CPU. I grant you that some additional sophistication may be necessary, but I suspect that this is not going to become more >complicated than polynomial evaluation.

I'm not scared of polynomial evaluation, but the fact that my IGP 
implementation is dependent on the PD specifics, which are not generally 
available and need to be custom built for each PD specifically. I always 
thought a good IGP implementation is PD agnostic.

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Feb 2020 17:48:49 +0000

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 <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, February 19, 2020 1:07 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
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.

On Wed, Feb 19, 2020 at 3:26 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Two recent drafts advocate for the use of faster LSP flooding speeds in IS-IS:

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Feb 2020 17:58:43 +0000

Tony -

Peter has a done a great job of highlighting that "single queue" is an oversimplification - I have nothing to add to that discussion.

I would like to point out another aspect of the Rx based solution.

As you need to send signaling based upon dynamic receiver state and this signaling is contained in unreliable PDUs (hellos) and to be useful this signaling needs to be sent ASAP - you cannot wait until the next periodic hello interval (default 10 seconds) to expire. So you are going to have to introduce extra hello traffic at a time when protocol input queues are already stressed.

Given hellos are unreliable, the question of how many transmissions of the update flow info is enough arises. You could make this more deterministic by enhancing the new TLV to include information received from the neighbor so that each side would know when the neighbor had received the updated info. This then requires additional hellos be sent in both directions - which exacerbates the queue issues on both receiver and transmitter.

It is true (of course) that hellos should be treated with higher priority than other PDUs, but this does not mean that the additional hellos have no impact on the queue space available for LSPs/SNPs.

Also, it seems like you are proposing interface independent logic, so you will be adjusting flow information on all interfaces enabled for IS-IS, which means that additional hello traffic will occur on all interfaces. At scale this is concerning.

   Les

> -----Original Message-----
> From: Peter Psenak <[email-masked]>
> Sent: Wednesday, February 19, 2020 2:49 AM
> To: Tony Li <[email-masked]>
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked];
> [email-masked]
> architecture may have different number of queues involved, etc. Trying to
> find a common value to report to IPGs across various PDs would involve
> some PD specific logic and that is the part I'm referring to and I would like
> NOT to get into.
> >
> >
> > I’m sorry that scares you.  It would seem like an initial implementation
> might be to take the min of the free space of the queues leading from the
> >interface to the CPU. I grant you that some additional sophistication may be
> necessary, but I suspect that this is not going to become more >complicated
> than polynomial evaluation.
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Feb 2020 19:55:07 +0100

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) <[email-masked]>
wrote:

> Robert –
>
>
>
> Thanx for your input.
>
>
>
> Note that one of the suggestions in
>  is to prioritize the reception of SNPs over LSPs so that we are less
> likely to drop ACKs.
>
> 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 <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, February 19, 2020 1:07 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> Hi Les & all,
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Feb 2020 19:10:05 +0000

Robert –

Sure – we can add some text in this area.

Implementations which don’t do well at current flooding speeds clearly won’t do well at faster flooding speeds unless they are enhanced. And such implementations won’t do well at scale even w/o faster flooding.
As always with these kinds of improvements, deployment has to be done carefully. I suppose this argues for more discussion of deployment considerations.
Added to the list…

   Les

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, February 19, 2020 10:55 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

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) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

Thanx for your input.

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Wednesday, February 19, 2020 1:07 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hi Les & all,

Thx,
Robert.

---

From: [email-masked]
Date: Thu, 20 Feb 2020 06:25:23 +1100

Peter,

> I'm not scared of polynomial evaluation, but the fact that my IGP implementation is dependent on the PD specifics, which are not generally available and need to be custom built for each PD specifically. I always thought a good IGP implementation is PD agnostic.

Your implementation is always dependent on the underlying hardware.  We have timers, we have filesystems, we have I/O subsystems, threads, and clocks to contend with. The input queue in the hardware is a fact of life and knowing about it can improve our implementations.

Because the PD layer can provide isolation from the specifics, the IGP implementation is reasonably abstracted from those specifics, in much the same way that the OS has abstracted us from the remainder of the underlying hardware. All I’m proposing is adding one more item to that PD abstraction.

Regards,
Tony

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 19 Feb 2020 11:24:54 -0800

Having worked for last couple of years on implementation of flooding speeds
that converge LSDBs some order of magnitudes above today's speeds  ;-)
here's a bunch of observations

1. TX side is easy and useful. My observation having gone quickly over the
-ginsberg- draft is that you really want a better hysterisis there, it's
bit too vertical and you will generate oscillations rather than walk around
the equilibrium ;-)
2. Queue per interface is fairly trivial with modern implementation
techniques and memory sizes if done correctly. Yes, very memory constrained
platforms are a mildly different game and kind of precondition a different
discussion.
3. RX side is possible and somewhat useful but much harder to do well
depending on flavor. If we're talking about the RX advertising a very
static value to cap the flooding speed that's actually a useful knob to
have IMO/IME. Trying to cleverly communicate to the TXer a window size is
not only fiendishly difficult, incurs back propagation speed (not
neglectible @ those rates IME) but can easily lead to subtle flood
starvation behaviors and lots of slow starts due to mixture of control loop
dynamics and implementation complexity of such a scheme. Though, giving the
TXer some hint that a backpressure is desired is however not a bad thing
IME and can be derived failry easily without needs for checking queue sizes
and so on. It's observable by looking @ some standard stats on what is
productive incoming rate on the interface. Anything smarter needs new TLVs
on packets & then you have a problem under/oversampling based on hellos
(too low a frequency) and ACKs (too bursty, too batchy) and flooded back
LSPs (too unpredictable)

For more details I can recommend rift draft of course ;-)

otherwise I'm staying out from this mildly feline spat ;-)

--- tony

On Wed, Feb 19, 2020 at 9:59 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Tony -
>
> Peter has a done a great job of highlighting that "single queue" is an
> oversimplification - I have nothing to add to that discussion.
>
> As you need to send signaling based upon dynamic receiver state and this
> signaling is contained in unreliable PDUs (hellos) and to be useful this
> signaling needs to be sent ASAP - you cannot wait until the next periodic
> hello interval (default 10 seconds) to expire. So you are going to have to
> introduce extra hello traffic at a time when protocol input queues are
> already stressed.
>
> Given hellos are unreliable, the question of how many transmissions of the
> update flow info is enough arises. You could make this more deterministic
> by enhancing the new TLV to include information received from the neighbor
> so that each side would know when the neighbor had received the updated
> info. This then requires additional hellos be sent in both directions -
> which exacerbates the queue issues on both receiver and transmitter.
>
> It is true (of course) that hellos should be treated with higher priority
> than other PDUs, but this does not mean that the additional hellos have no
> impact on the queue space available for LSPs/SNPs.
>
> Also, it seems like you are proposing interface independent logic, so you
> will be adjusting flow information on all interfaces enabled for IS-IS,
> which means that additional hello traffic will occur on all interfaces. At
> scale this is concerning.
>
>    Les
>
>
> > necessary, but I suspect that this is not going to become more
> >complicated

---

From: [email-masked]
Date: Thu, 20 Feb 2020 06:29:21 +1100

Les,

> As you need to send signaling based upon dynamic receiver state and this signaling is contained in unreliable PDUs (hellos) and to be useful this signaling needs to be sent ASAP - you cannot wait u…

I am not proposing that we add additional packets at this time.  Yes, I realize that it may limit the effectiveness of the feedback, but without serious experimentation, the cure may be worse than the disease.  I propose to tread very carefully.

> Given hellos are unreliable, the question of how many transmissions of the update flow info is enough arises. You could make this more deterministic by enhancing the new TLV to include information…

I am not proposing this.  If the hello is lost, then the transmitter has less information to work with, which is not an unreasonable situation.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Feb 2020 20:42:16 +0100

Tony,

On 19/02/2020 20:25, [email-masked] wrote:
>> implementation is dependent on the PD specifics, which are not 
>> generally available and need to be custom built for each PD 
>> specifically. I always thought a good IGP implementation is PD agnostic.
> 
> 
> Your implementation is always dependent on the underlying hardware.  We 
> have timers, we have filesystems, we have I/O subsystems, threads, and 
> clocks to contend with. 

none of the above is dependent on the LC specific hardware.

> The input queue in the hardware is a fact of 
> life and knowing about it can improve our implementations.
> 
> Because the PD layer can provide isolation from the specifics, the IGP 
> implementation is reasonably abstracted from those specifics, in much 
> the same way that the OS has abstracted us from the remainder of the 
> underlying hardware. All I’m proposing is adding one more item to that 
> PD abstraction.

easy to say with a single PD. If you have 20, each with a different 
architecture, it becomes a different problem.

thanks,
Peter

---

From: [email-masked]
Date: Thu, 20 Feb 2020 06:59:39 +1100

> easy to say with a single PD. If you have 20, each with a different architecture, it becomes a different problem.

My employer has multiple PD implementations. I sympathize, but it’s still necessary.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Feb 2020 20:53:29 +0000

Tony -

With respect, it is hard to know what you are proposing since there has never been a public description.

The draft on which you are a co-author does not discuss any sort of algorithm to dynamically alter the advertised value based on current router state. In fact it argues (or at least suggests) that this shouldn't be done. Section 5 states:

" ... a reasonable choice
   might be for a node to 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.  With such a
   formula, the values advertised in the Flooding Speed TLV would only
   change when additional IS-IS interfaces are configured.  On the other
   hand, it would be undesirable to use a formula that depends, for
   example, on an active measurement of the CPU load to modify the
   values advertised in the Flooding Speed TLV..."

Apparently you have a different idea, which maybe the next version of draft-decraene will include, but right now all we have as a description is a series of isolated sentences in multiple emails. You'll have to forgive me if I am not always clear about what you intend but have yet to state.

Inline.

> Sent: Wednesday, February 19, 2020 11:29 AM
> Cc: Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
> introduce extra hello traffic at a time when protocol input queues are already
> stressed.
> 
> 
> I am not proposing that we add additional packets at this time.  Yes, I realize
> that it may limit the effectiveness of the feedback, but without serious
> experimentation, the cure may be worse than the disease.  I propose to
> tread very carefully.
> 
> 
[Les:] So you intend to simply update the feedback in the next scheduled hello?

If so, this is interesting choice.

The occurrence of high flooding rates is an infrequent event. When it occurs, it will persist for some finite amount of time - which with higher flooding rates we hope will be modest - in the 10s of seconds or less.
If you aren't going to signal "slow down" for up to 10 seconds, the impact of the control is significantly diminished.

This is another significant difference relative to  the TCP analogy. For a TCP session it is quite reasonable to expect that high sustained throughput is desired for long periods of time.
For IGP flooding, high sustained throughput occurs rarely - and is of limited duration.

    Les

> update flow info is enough arises. You could make this more deterministic by
> enhancing the new TLV to include information received from the neighbor so
> that each side would know when the neighbor had received the updated
> info. This then requires additional hellos be sent in both directions - which
> exacerbates the queue issues on both receiver and transmitter.
> 
> 
> I am not proposing this.  If the hello is lost, then the transmitter has less
> information to work with, which is not an unreasonable situation.
> 
> Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Feb 2020 22:01:18 +0000

Tony –

If you have a suggestion for Tx back-off algorithm please feel free to share.
The proposal in the draft is just a suggestion.
As this is a local matter there is no interoperability issue, but certainly documenting a better algorithm is worthwhile.

   Les (claws in check 😊 )

From: Tony Przygienda <[email-masked]>
Sent: Wednesday, February 19, 2020 11:25 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Peter Psenak (ppsenak) <[email-masked]>; Tony Li <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Having worked for last couple of years on implementation of flooding speeds that converge LSDBs some order of magnitudes above today's speeds  ;-) here's a bunch of observations

1. TX side is easy and useful. My observation having gone quickly over the -ginsberg- draft is that you really want a better hysterisis there, it's bit too vertical and you will generate oscillations rather than walk around the equilibrium ;-)
2. Queue per interface is fairly trivial with modern implementation techniques and memory sizes if done correctly. Yes, very memory constrained platforms are a mildly different game and kind of precondition a different discussion.
3. RX side is possible and somewhat useful but much harder to do well depending on flavor. If we're talking about the RX advertising a very static value to cap the flooding speed that's actually a useful knob to have IMO/IME. Trying to cleverly communicate to the TXer a window size is not only fiendishly difficult, incurs back propagation speed (not neglectible @ those rates IME) but can easily lead to subtle flood starvation behaviors and lots of slow starts due to mixture of control loop dynamics and implementation complexity of such a scheme. Though, giving the TXer some hint that a backpressure is desired is however not a bad thing IME and can be derived failry easily without needs for checking queue sizes and so on. It's observable by looking @ some standard stats on what is productive incoming rate on the interface. Anything smarter needs new TLVs on packets & then you have a problem under/oversampling based on hellos (too low a frequency) and ACKs (too bursty, too batchy) and flooded back LSPs (too unpredictable)

--- tony

On Wed, Feb 19, 2020 at 9:59 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Tony -

   Les

> From: Peter Psenak <[email-masked]<mailto:[email-masked]>>
> To: Tony Li <[email-masked]<mailto:[email-masked]>>
> Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 19 Feb 2020 16:20:21 -0800

My sense of humor to be excused, Les 😗😁

Yes, so here's suggestion taht will build a better sloped hysteresis that
will allow you to ramp up slower first to not oscillate and also ramp down
somewhat more graciously. It's a sketch, more interesting metrics can be
taken into it further but that's the flavor good enough for the draft IMO.
holding down on timer is better achieved by 'normalizing' by exponential
decay on every tick that 'primes' to max rate over time when nothing is
happening.  Queue lengths except somle low/high watermark that stops/starts
sending are quite misleading IME given that queue length is not very
meaningful unless one can measure producer/consumer rates and those depend
largely on CPU cycles available & memory congestion and can be very, very
bursty. And all the queues involved as well to an extent (IME in halfway
non-trivial architecture @ least 3 of those in- and out- the box).

MaxAllowedEver/sec = maximum rate ever allowed (constant)
MinAllowedEver/sec = minimum rate ever allowed (constant)
MaxAllowedRate/sec = maximum packets (CSNP/PSNP/LSP) allowed out the
interface per sec
CurrentRate/sec = packets sent out this second
Re-TX/sec = retransmissions this second

per every second tic:

if Re-TX {
    CurrentRate/sec = max(MinAllowedEver, CurrentRate - 30% ) // slope down
fast on re-tx
}

if CurrentRate/sec >= MaxAllowedRate/sec {
  MaxAllowedRate/sec = min(MaxAllowedEver, MaxAllowedRate + 20%) // when
under load slope up fast
} else {
  MaxAllowedRate/sec += min(MaxAllowedRate, CurrentRate + 5%) // slowly
normalizes even if no traffic
}

What you write about ack'ing only is dangerous and can seriously affect the
protocol. If you're holding newer LSPs than the ones received ack'ing old
versions is not helpful. one should flood back newer stuff. Generally it is
better to run proper WFQ per type and not just start send one type of
packets since that can hit ugly corner conditions in flooding & starve it
IME if the queues get long enough one can't drain them in a sec tic.

hope that's precise & lucid enough without smothering folks with too much
detail ...

--- tony

On Wed, Feb 19, 2020 at 2:01 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> As this is a local matter there is no interoperability issue, but
> certainly documenting a better algorithm is worthwhile.
>
>
>
>    Les (claws in check 😊 )
>
>
>
>
>
> *From:* Tony Przygienda <[email-masked]>
> *Sent:* Wednesday, February 19, 2020 11:25 AM
> *Cc:* Peter Psenak (ppsenak) <[email-masked]>; Tony Li <
> [email-masked]>; [email-masked]; [email-masked]
> Having worked for last couple of years on implementation of flooding
> speeds that converge LSDBs some order of magnitudes above today's speeds
> ;-) here's a bunch of observations
>
>
>
> On Wed, Feb 19, 2020 at 9:59 AM Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Tony -
>

---

From: Tony Li <[email-masked]>
Date: Thu, 20 Feb 2020 09:58:56 +1100

Les,

> With respect, it is hard to know what you are proposing since there has never been a public description.

With respect, I’ve said it many times, both in person and in email. You need to hear it again? Sure.

> The draft on which you are a co-author does not discuss any sort of algorithm to dynamically alter the advertised value based on current router state. In fact it argues (or at least suggests) that this shouldn't be done.

I’m suggesting being more dynamic than what that draft advocates.

> Apparently you have a different idea, which maybe the next version of draft-decraene will include, but right now all we have as a description is a series of isolated sentences in multiple emails. Y…

Again, what I’m suggesting is that the LSP receiver use a TLV (possibly Bruno’s, possibly tweaked) to tell the LSP transmitter the current space in the input packet queue. As previously described, we may want to consider oversubscription when advertising this value. This MAY be included in IIH’s and SNP’s, piggy backed on existing transmissions. 

The LSP transmitter MAY use this information, in conjunction with the knowledge of unacknowledged LSPs, to optimize the transmission rate. If no information is learned from the LSP receiver, the LSP transmitter is no worse off. If the information that was learned is old, then LSP transmitter is free to ignore it.

If the LSP receiver can’t provide a useful value (e.g., if the PD layer hasn’t been implemented), it is free to provide either the static value or no value.

As always, I am expecting that implementation experience and inter-operability testing will contribute to this effort, and I am not expecting the right answer in the first pass.

Tony

---

From: <[email-masked]>
Date: Wed, 26 Feb 2020 18:33:43 +0000

Les,

From: Lsr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 6:49 PM
To: Robert Raszuk
Cc: [email-masked]
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Robert –

Thanx for your input.

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.
[Bruno]
So you need a new behavior on the Rx side (Rx with respect to LSP).  This is _not_ Tx only with no need for protocol change.
And BTW, this is called a feedback from the Rx to the Tx.

As we change the protocol on the Rx side, we have the opportunity to report more information from Rx to the Tx.

--Bruno

   Les

Hi Les & all,

Thx,
Robert.

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Wed, 26 Feb 2020 19:03:21 +0000

Les,

Please see inline[Bruno]

From: Lsr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 3:32 AM
To: [email-masked]
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

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..

[Bruno] _Assuming_ that the parameters are static, those parameters

o   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?

§  There is also the option to reply: I don't know but don't care as I leave the issue to the network operator.

o   can still provide some form of dynamicity, by using the PSNP as dynamic acknowledgement.

o   are 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)."

o   And 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

    Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Feb 2020 19:04:16 +0000

Bruno –

I know there are more issues behind your comment, but sending PSNPs in response to receipt of LSPs is base protocol behavior – there is nothing new here.
And sending them in a timely manner is also nothing new.
I think the discussion with Robert was only that – in the context of greater scale/faster flooding – keeping the delay in sending PSNP to a small value becomes more important.

There is a legitimate discussion to be had as to whether additional information from the receiver is useful – and that discussion has started.
If there is agreement on the need for new information we can then discuss in what form to send it. New TLV in hellos has been mentioned.  It is conceivable that new TLV in SNPs could be used – though this would be less appealing on LANs.

But first we have to agree on whether new information should be sent at all.

   Les

From: [email-masked] <[email-masked]>
Sent: Wednesday, February 26, 2020 10:34 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: RE: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Les,

Robert –

Thanx for your input.

--Bruno

   Les

Hi Les & all,

Thx,
Robert.

Thank you.