Re: [Lsr] Dynamic flow control for flooding

["Les Ginsberg (ginsberg)" <[e-mail]>]

Tony -

From: Tony Li <[e-mail]> On Behalf Of [e-mail]
Sent: Wednesday, July 24, 2019 3:37 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Lsr] Dynamic flow control for flooding


Les,


If you disagree please take things bullet-by-bullet:


  *   LSP input queue implementations are typically interface independent FIFOs


Very true.  It would not be unreasonable for an implementation to report free space in the FIFO (in number of PDUs) divided by the number of active adjacencies.  Everyone gets their fair share.

[If dynamic flooding is enabled, this could be based on the number of adjacencies that should be actively flooding. That should be a much smaller number.]
[Les:] So you are agreeing that when a receiver wants to “dial back” it will need to do so on all interfaces enabled for flooding?



  *   Overloaded Receiver does not know which senders are disproportionately causing the overflow


This doesn’t matter.  The receiver needs them all to slow down.



  *   LSPs may be dropped at lower layers – IS-IS receiver may be unaware that the overload condition exists


That’s an implementation problem. The implementation NEEDS to be able to see its input queue plus input drops.

[Les:] And you want to ship this feature when…? 😊
I think this is a difficult ask.
Before we decide this is what is required we should explore the path of monitoring the unacknowledged Tx queue.


  *   Updating hellos dynamically to alter flooding transmission rate is an OOB signaling mechanism consuming  resources at a time when routers are the most busy
  *   Consistent flooding rates will require updated hellos be sent to all neighbors – exacerbating the cost on both sender and receiver


This is why I suggest sending the feedback in PSNPs as well as in IIHs.  Regardless of the details, we need to consider sending PSNPs back more frequently.  I concur that optimizing the rate and triggers for sending more PSNPs is an open issue.

Strictly speaking, sending a TLV inside of our protocol PDUs is an in-band signaling mechanism.
[Les:] I agree – PSNP would be better since we need to send it anyway in order to ACK. Still does not convince me this is the preferred approach – but I agree it is better than hellos.

The resources consumed by maintaining a running count of a queue in silicon or in process space is effectively zero.

[Les:] It is not about counting – it is about how a given queue might be used. It isn’t reasonable to mandate that a dataplane-to-forwarding plane queue be dedicated to IS-IS. What other control plane entities are using the queue and how they empty it will introduce new variables. And the implementation cost comes in providing “real time updates” on the current queue space to clients that need it.

I really think monitoring the unacknowledged TX queue will give us what we need and make the solution completely contained within the IS-IS implementation.
Guess I need to work on more details on that approach.

   Les


Tony