Henk - Welcome to the discussion.
Inline. > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Wednesday, July 24, 2019 5:34 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: [email protected]; Tony Li <[email protected]>; [email protected] > Subject: Re: [Lsr] Dynamic flow control for flooding > > > Hello Les, > > Les Ginsberg (ginsberg) schreef op 2019-07-24 07:17: > > > > There is something to be said for simply “flooding fast” and not > > worrying about flow control at all (regardless of whether TX or RX > > mechanisms would be used). Some packets would be dropped, but > > retransmission timers will insure that the flooding eventually > > succeeds and retransmit timers are long (5 seconds by default). (I am > > not the only one mentioning this BTW…) > > Why do we have initial waits and exponential backoffs for LSP-generation > and SPF-computations ? Why not react immediately ? Why not react > constantly ? > [Les:] I think you know what I am about to say.. 😊 Initial wait exists in order to minimize premature SPF calculation. Topology changes always entail multiple LSP updates (often 2 for a single link failure - more for a node failure or line card failure). We wait a short while to increase the likelihood that we have received all of the LSP updates associated w the topology event. Backoff is used so that if the network has an extended period of instability we do not invest cycles w diminishing returns i.e., the updates we are making to forwarding are likely stale before we even complete the update. > We have a lot of bandwidth and cpu-power now. Isn't simple always better > than "overly complex stuff" like exponential backoffs ? If you have more > cpu-power, more memory and more bandwidth, why invent new algorithms ? [Les:] Base spec never defined an algorithm for dynamically changing flooding speed (unless you consider retransmit timers). So this is "inventing" - not "reinventing". Les > > henk. > > > I hope it is clear to everyone that these are not serious questions. I'm > just > saying: "sometimes fast is slow". I am sure that if we ask the "old > guys", they > can come up with many stories how these problems are sometimes > counter-intuitive. > And how networks have melted because "fast is slow". I could tell at > least 2 > of those stories myself. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
