Les, Ok, let me reset. I’ve re-read your slides. I don’t see anything in there about changing the PSNP signaling rate. From your comments to Henk, I infer that you’re open to changing that rate.
As soon as you do that, you’re now providing receiver based feedback and creating flow control. You’re accepting that rates will vary per interface. What you’re NOT doing is providing information about the receiver’s input queue and requested input rate. With less information, the transmitter can only approximate the optimal rate and your proposal seems like a Newton’s method approach to determining that rate. Your proposal depends on two constants: Usafe and Umax. How do you know what those are? That’s information about the receiver. I infer that you propose to hard code some conservative values for these. In my mind, that implies that you will be going more slowly than you could if you had more accurate data. And pretty much what we’re proposing is that the receiver advertise this type of information so that we don’t have to assume the worst case. This also is nice because an implementation only has to know about it’s own capabilities. Tony > On Jul 24, 2019, at 12:31 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> > wrote: > > Tony – > > I have NEVER proposed that the flooding rate be determined by the slowest > node. > Quite the opposite. > > Flooding rate should be based on the target convergence time and should be > aggressive because most topology changes involve much fewer than 1000 LSPs > (arbitrary number). So even w a slow node fast flooding won’t be an issue for > the vast majority of changes. > > When we get a topology change with enough LSPs to expose the slowest node > limitations we (in decreasing order of importance): > > 1)Continue to flood fast to those nodes/links which can handle it > 2)Report the slow node to the operator (so they can address the limitation) > 3)Do what we can to limit the overload on the slow node/link > > Hope this helps. > > Les > > > From: Tony Li <tony1ath...@gmail.com <mailto:tony1ath...@gmail.com>> On > Behalf Of tony...@tony.li <mailto:tony...@tony.li> > Sent: Wednesday, July 24, 2019 12:04 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com>> > Cc: lsr@ietf.org <mailto:lsr@ietf.org> > Subject: Re: [Lsr] Dynamic flow control for flooding > > > Les, > > > Optimizing the throughput through a slow receiver is pretty low on my list > because the ROI is low. > > > Ok, I disagree. The slow receiver is the critical path to convergence. Only > when the slow receiver has absorbed all changes and SPFed do we have > convergence. > > > 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. > > > Rate limiting flooding delays convergence. Please consider the following > topology: > > > 1 —————— 2 —————— 3 > | | | > | | | > 4 —————— 5 —————— 6 > | | | > | | | > 7 —————— 8 —————— 9 > > > Suppose that we have 1000 LSPs injected at router 1. Suppose further that > router 2 runs at half the rate of router 4. [How router 1 knows this > requires $DEITY and is out of scope for the moment.] > > Router 1 now floods at the optimal rate for router 2. Router 1 uses that > same rate to flood to router 4. Suppose that it takes time T for this to > complete. > > When does the network converge? > > Option 1: All nodes use the same flooding rate. > > Router 2 will flood to router 3 concurrent with receiving updates from router > 1. Thus, router 3 will receive all updates in time T + delta, where delta is > router 2’s processing time. For now, let’s approximate delta as zero. > > Similarly, all routers will use the same rate, so router 4 will flood to 7 in > time T + delta, and so on, with router 9 receiving everything in time T + 3 * > delta. > > Assuming no nodes SPF during the process, the network converges nearly > simultaneously in about time T. > > Option 2: We flood a bit faster where we can. > > Suppose that router 1 now floods at the full rate to router 4. The full > update now takes time T/2. Because all of the other nodes in the network are > fast, router 4 floods in time T/2 + delta to nodes 5 and 7. Carrying this > forward, router 9 gets a full update in time T/2 + 3 * delta. Even router 3 > has full updates in T/2 + 3 * delta. > > With the exception of node 2, the network has converged in half the time. > Even node 2 converges in time T. > > Key points: > > 1) Yes, the slow node delays convergence and causes micro-loops as everyone > around it SPFs. The point here (and I think you agree) is that slow nodes > need to be upgraded. > > 2) There is no way for us to know how fast a node can go without some form of > flow control, other than to go absurdly slowly. > > 3) There are many folks who want to converge quickly. It is mission critical > for them. They will address slow nodes. They will not accept pessimal timing > to avoid micro-loops. > > > > [Les:] I do not see how flow control improves things. > > > Flow control allows the transmitter to transmit at the optimal rate for the > receiver. > > > > 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. > > > How is that different than what you’ve proposed? Router 1 can only flood at > the rate that it gets PSNPs from router 2. That paces its flooding to router > 4. Following that logic, you somehow want router 4 to run at the same rate, > forcing a uniformly slow rate. > > Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
