Les, > 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).
The only thing I would say to that is: really bad idea. If you supersaturate the receiver, you waste transmitter in the transmission, you swamp the receiver causing packet loss, you potentially trigger the loss of IIH’s, you risk causing a cascade failure, and until we come up with a better retransmission mechanism, you probably actually delay network convergence, as nothing is going to happen until you’ve completed retransmissions. The way to maximize goodput is NOT to transmit blindly. > But most important to me is to recognize that flow control (however done) is > not fixing anything – nor making the flooding work better. The network is > compromised and flow control won’t fix it. ???? The network is not compromised. > If you accept that, then it makes sense to look for the simplest way to do > flow control and that is decidedly not from the RX side. (I expect Tony Li to > disagree with that 😊– but I have already outlined why it is more complex to > do it from the Rx side.) Flow control cannot be done without involvement of the RX side. That’s why it’s called flow _control_. The only thing that can be done purely from the TX side is a unilateral (and pessimal) transmit rate cap that will have to allow for the worst case CPU in the worst case situation (e.g., BGP impacting the CPU). Flow control is the creation of a control loop and that requires feedback from the receiver. This is true in every form of true flow control: XON/XOFF, RTS/CTS, sliding window protocols, credit based fabric mechanisms, etc. I’ll go so far as to quote Wikipedia: "In data communications <https://en.wikipedia.org/wiki/Data_communications>, flow control is the process of managing the rate of data transmission between two nodes to prevent a fast sender from overwhelming a slow receiver. It provides a mechanism for the receiver to control the transmission speed, so that the receiving node is not overwhelmed with data from transmitting node.” Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
