Re: [Lsr] Dynamic flow control for flooding

[<[e-mail]>]

Les,

Can’t we use from a transmitter point of view, the lack of ACKs from the receiver as a signal that the transmitter should slow down ?
I agree that depending on the exact bottleneck/issue, the IS-IS stack of the receiver may not be aware that something bad is happening and can’t provide feedback to the transmitter. However if the transmitter sees that the receiver is acking slowly or quickly, wouldn’t it be able to adjust its flooding speed. Can we have a receiver intentionally postponing a PSNP to aggregate multiple ACKs in a single message ?

From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
Sent: Wednesday, July 24, 2019 14:48
To: [e-mail]
Cc: LITKOWSKI Stephane OBS/OINIS; [e-mail]
Subject: RE: [Lsr] Dynamic flow control for flooding

More inline…

From: Tony Li <[e-mail]> On Behalf Of [e-mail]
Sent: Tuesday, July 23, 2019 10:56 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Lsr] Dynamic flow control for flooding


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.

[Les:] I have to watch my words more closely. 😊
I am not arguing for this – but I do think that “most of the time” this strategy would actually be optimal.
We are discussing the extreme cases – as we should – where we have a large # of LSPs to flood. But let’s not lose sight of the fact that the simple approach works most of the time. For the times when the simple approach doesn’t work well, I am then arguing we should not overcomplicate the solution – particularly because the strategies we might use don’t help convergence.

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.
[Les:] Prioritization of hellos over LSPs/SNPs is a longstanding best practice (both on Tx and Rx) and this must not change. No one is advocating that – certainly not me.

The way to maximize goodput is NOT to transmit blindly.


[Les:] Not arguing for blindness, but I am arguing for simplicity.

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.

[Les:] If the SLA the customer expects is convergence in less than N, then a slow link jeopardizes our ability to achieve that.

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.”

[Les:] I will not argue about the definition.
In this specific case, there are difficulties in controlling the flooding rate based on advertisements from the RX side. The difficulties are outlined in my slides and largely have to do with the difficulties/costs of dynamically calculating what number to advertise. (A static advertisement is also difficult to calculate w/o being overly conservative.)

If you disagree please take things bullet-by-bullet:


  *   LSP input queue implementations are typically interface independent FIFOs
  *   Overloaded Receiver does not know which senders are disproportionately causing the overflow
  *   LSPs may be dropped at lower layers – IS-IS receiver may be unaware that the overload condition exists
  *   Updating hellos dynamically to alter flooding transmission rate is an OOB signaling mechanism consuming  resources at a time when routers are the most busy
  *   Consistent flooding rates will require updated hellos be sent to all neighbors – exacerbating the cost on both sender and receiver

   Les

Tony


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.