Tony –
There is no such assumption.
Transmitter has exact knowledge of how many unacknowledged LSPs have been
transmitted on each interface.
Using an algorithm functionally equivalent to the example algorithm in the
draft, the transmitter slows down when the neighbor is not acknowledging in a
timely manner LSPs sent on that interface.
The reason the neighbor is falling behind is irrelevant.
Maybe the receiver has a per interface queue and the associated line card is
overloaded.
Maybe the receiver has a single queue but there are so many LSPs received on
other interfaces in the front of the queue that the receiver hasn’t yet
processed the ones received on this interface.
Maybe the receiver received the same LSPs on other interfaces and is now so
busy sending these LSPs that it has fallen behind on processing its receive
queue.
Maybe BGP is consuming high CPU and starving IS-IS…
The transmitter doesn’t care. It just adjusts the transmission rate based on
actual performance.
If all interfaces on the receiver are backed up all the neighbors will slow
down their transmission rate.
The TX side flow control is purely based on performance on each interface –
there are no implementation requirements imposed or implied as regards the
receiver.
Les
From: Tony Li <[email protected]>
Sent: Tuesday, February 18, 2020 7:10 PM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: [email protected]
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/
advocates for a transmit based flow control where the transmitter monitors the
number of unacknowledged LSPs sent on each interface and implements a backoff
algorithm to slow the rate of sending LSPs based on the length of the per
interface unacknowledged queue.
Les,
This makes the assumption that there is a per-interface queue on the LSP
receiver. That has never been the case on any implementation that I’ve ever
seen.
Without this assumption or more information, it seems difficult for the LSP
transmitter to have enough information about how to proceed.
Tony
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
