Re: [Lsr] Dynamic flow control for flooding

[[e-mail]]

Les,


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


Certainly.  There’s one CPU, one input queue.   If there’s a flooding event in progress, then it’s likely to arrive from all sides.  Dialing back on all interfaces makes sense as self-preservation.


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


That’s the tail wagging the dog.  

I’m less concerned about when.  The people who want this feature are going to pay for it.  They will set the agenda and schedule, not us.  We need to figure out how to do it properly.

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


Please note that I prefer BOTH.  Sending it in IIHs is useful because it allows adjacencies that are not expecting a PSNP to still get some feedback. It would also prevent problems that we’ve seen with TCP and connections getting stuck with a zero window.


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


Well, that’s up to your implementation.  Even if it is a shared queue, it has a finite depth and the transmitter should not overrun it. Scale your numbers accordingly.


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


Please focus on how the transmitter distinguishes between packets lost and packets queued at the receiver.

Both imply that the TX rate was too high.  One suggests that retransmissions should be expedited.  The other suggests that they should not.

Tony