Tony - With respect, it is hard to know what you are proposing since there has never been a public description.
The draft on which you are a co-author does not discuss any sort of algorithm to dynamically alter the advertised value based on current router state. In fact it argues (or at least suggests) that this shouldn't be done. Section 5 states: " ... a reasonable choice might be for a node to use a formula based on an off line tests of the overall LSPDU processing speed for a particular set of hardware and the number of interfaces configured for IS-IS. With such a formula, the values advertised in the Flooding Speed TLV would only change when additional IS-IS interfaces are configured. On the other hand, it would be undesirable to use a formula that depends, for example, on an active measurement of the CPU load to modify the values advertised in the Flooding Speed TLV..." Apparently you have a different idea, which maybe the next version of draft-decraene will include, but right now all we have as a description is a series of isolated sentences in multiple emails. You'll have to forgive me if I am not always clear about what you intend but have yet to state. Inline. > -----Original Message----- > From: Tony Li <[email protected]> On Behalf Of [email protected] > Sent: Wednesday, February 19, 2020 11:29 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Peter Psenak (ppsenak) <[email protected]>; [email protected] > Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed > > > Les, > > > As you need to send signaling based upon dynamic receiver state and this > signaling is contained in unreliable PDUs (hellos) and to be useful this > signaling needs to be sent ASAP - you cannot wait until the next periodic > hello interval (default 10 seconds) to expire. So you are going to have to > introduce extra hello traffic at a time when protocol input queues are already > stressed. > > > I am not proposing that we add additional packets at this time. Yes, I > realize > that it may limit the effectiveness of the feedback, but without serious > experimentation, the cure may be worse than the disease. I propose to > tread very carefully. > > [Les:] So you intend to simply update the feedback in the next scheduled hello? If so, this is interesting choice. The occurrence of high flooding rates is an infrequent event. When it occurs, it will persist for some finite amount of time - which with higher flooding rates we hope will be modest - in the 10s of seconds or less. If you aren't going to signal "slow down" for up to 10 seconds, the impact of the control is significantly diminished. This is another significant difference relative to the TCP analogy. For a TCP session it is quite reasonable to expect that high sustained throughput is desired for long periods of time. For IGP flooding, high sustained throughput occurs rarely - and is of limited duration. Les > > Given hellos are unreliable, the question of how many transmissions of the > update flow info is enough arises. You could make this more deterministic by > enhancing the new TLV to include information received from the neighbor so > that each side would know when the neighbor had received the updated > info. This then requires additional hellos be sent in both directions - which > exacerbates the queue issues on both receiver and transmitter. > > > I am not proposing this. If the hello is lost, then the transmitter has less > information to work with, which is not an unreasonable situation. > > Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
