*[Les:] At the cost of convergence. Not a good tradeoff.* Hi Les - why at the cost of convergence ? No one as I see it is proposing the same rate to every peer. Quite contrary -- per peer rate of flooding. So if you keep flooding high speed on fast links the convergence will not be any slower with flow control.
Thx, R. On Wed, Jul 24, 2019 at 8:28 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Tony – > > > > Inline. > > > > *From:* Tony Li <tony1ath...@gmail.com> *On Behalf Of *tony...@tony.li > *Sent:* Tuesday, July 23, 2019 10:39 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* lsr@ietf.org > *Subject:* Re: [Lsr] Dynamic flow control for flooding > > > > > > > > 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. > > > > *[Les:] My goals are:* > > > > *Optimize convergence.* > > *Minimize complexity.* > > > > *Optimizing the throughput through a slow receiver is pretty low on my > list because the ROI is low.* > > > > 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. > > > > *[Les:] At the cost of convergence. Not a good tradeoff.* > > *I am arguing that we do want to flood at the same rate on all interfaces > used for flooding. When we cannot, flow control does not help with > convergence. It may decrease some wasted bandwidth – but as we all agree > that bandwidth isn’t a significant limitation this isn’t a great concern.* > > > > *The same reasons that drive us to use same SPF delay and LSP Generation > timers on all routers also apply to flooding rate.* > > > > 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. > > > > *[Les:] I do not see how flow control improves things.* > > *If you have alternate flooding paths around the slow link(s) this argues > more that you should not have the slow link in the flooding topology in the > first place. But this heads off topic – I think we agree that dynamic > flooding is a separate discussion which we don’t want to bring into this > thread.* > > > > 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. > > > > *[Les:] Never advocated that – please do not put those words in my mouth.* > > > > * Les* > > > > > > Tony > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
