Re: [Lsr] Dynamic flow control for flooding

[[e-mail]]

Les,

> I also think we all agree on the goal - which is to flood significantly faster than many implementations do today to handle deployments like the case you mention below.


I agree with that, but you haven’t responded to the goal that I proposed: keep the receiver processing PDUs.


> Beyond this point, I have a different perspective.
>  
> As network-wide convergence depends upon fast propagation of LSP changes – which in turn requires consistent flooding rates on all interfaces enabled for flooding – a properly provisioned network MUST be able to sustain a consistent flooding rate or the operation of the network will suffer. We therefore need to view flow control issues as indicative of a problem.
>  
> It is a mistake to equate LSP flooding with a set of independent P2P “connections” – each of which can operate at a rate independent of the other.
>  
> If we can agree on this, then I believe we will have placed the flow control problem in its proper perspective – in which case it will become easier to agree on the best way to implement flow control.


I agree that we want network wide convergence.  However, I disagree that the right thing to do is to uniformly flood at the same rate on all interfaces.

First, the rate that you select might be too fast for one neighbor and not for the others.  Real flow control would help address this.

Second, all flooding paths are not created equal.  You do not know, a priori, how to flood to get uniform network wide propagation.  The variance in CPU loading alone is going to cause different routers to flood at different rates, and so it may actaully be optimal to flood quickly down one path, knowing that the data will reach the other end of the network and flood back before the slow CPU can absorb and flood.

Dropping down to the least common denominator CPU speed in the entire network is going to be undoable without an oracle, and absurdly slow even with that.

Tony