Tony – Overall, I think you are making general statements and not providing needed specifics. Maybe it’s obvious to you how a receiver based window would be calculated – but it isn’t obvious to me – so please help me out here with specifics. What inputs do you need on the receive side in order to do the necessary calculation? What assumptions are you making about how an implementation receives, punts, dequeues IS-IS LSPs? And how will this lead to better performance than having TX react to actual throughput?
And please do not say “just like TCP”. I have made some specific statements about how managing the resources associated with a TCP connection is not at all similar to managing resources for IGP flooding. If you disagree – please provide some specific explanations. A few more comments inline – but rather than go back-and-forth on each line item, it would be far better if you wrote up the details of the RX side solution. Thanx. From: Tony Li <tony1ath...@gmail.com> On Behalf Of tony...@tony.li Sent: Tuesday, February 18, 2020 10:43 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: lsr@ietf.org Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed Les, Then the LSP transmitter is operating without information from the LSP receiver. Additional information from the receiver can help the transmitter maintain a more accurate picture of reality and adapt to it more quickly. [Les:] This is your claim – but you have not provided any specifics as to how information sent by the receiver would provide better adaptability than a Tx based flow control which is based on actual performance. This is not a claim. This is normally how control loops work. See TCP. When the receiver’s window opens, it can tell the transmitter. When the receiver’s window closes, it can tell the transmitter. If it only opens a little bit, it can tell the transmitter. [Les2:] TCP != IGP flooding – please see my remarks in my initial posting on this thread. Nor have you addressed how the receiver would dynamically calculate the values it would send. It can look at its input queue and report the current space. ~”Hi, I’ve got buffers available for 20 packets, totalling 20kB.”~ [Les2:] None of the implementations I have worked on (at least 3) work this way. For me how to do this is not at all obvious given common implementation issues such as: * Sharing of a single punt path queue among many incoming protocols/incoming interfaces The receiver gets to decide how much window it wants to provide to each transmitter. Some oversubscription is probably a good thing. [Les2:] That wasn’t my point. Neither of us Is advocating trying to completely eliminate retransmissions and/or transient overload. And since drops are possible, looking at the length of an input queue isn’t necessarily going to tell you whether you are indeed overloaded and if so due to what interface(s). Tx side flow control is agnostic to receiver implementation strategy and the reasons why LSPs remain unacknowledged.. * Single interface independent input queue to IS-IS itself, making it difficult to track the contribution of a single interface to the current backlog It’s not clear that this is problematic. Again, reporting the window size in this queue is helpful. [Les2:] Sorry, this is exactly the sort of generic statement that doesn’t add much. I know you believe this, but you need to explain how this is better than simply looking at what remains unacknowledged. * Distributed dataplanes This should definitely be a non-issue. An implementation should know the data path from the interface to the IS-IS process, for all data planes involved, and measure accordingly. [Les2:] Again, you provide no specifics. Measure “what” accordingly? IF I do not have a queue dedicated solely to IS-IS packets to be punted (and implementations may well use a single queue for multiple protocols) what should I measure? How to get that info to the control plane in real time? If we are to introduce new signaling/protocol extensions there needs to be good reason and it must be practical to implement – especially since we have an alternate solution which is practical to implement, dynamically responds to current state, and does not require any protocol extensions. If we are to introduce new behaviors, they must be helpful. Estimates that do not utilize the available information may be sufficiently erroneous as to be harmful (see silly window syndrome). [Les2:] Again – you try to apply TCP heuristics to IGP flooding. Not at all intuitive to me that this applies – I have stated why. Les Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
