Subject: [Lsr] IS-IS flooding

From: <[email-masked]>
Date: Tue, 3 Aug 2021 08:41:12 +0000

Les,

Thank you for the implementation and test results.
I have some clarification questions on your test results

S6:
What burst size did you use? And distributions of reals values if possible, if not (min, max, average, median) would be useful.
What scheduling frequency/period did you use on the sender?

S9:
Given that the sender seems to react after 1 second, it seems clear that feedback (PSNPs) was received before.
- How fast does the receiver sends PSNP? Is this default value or was that changed?
- What value did you use for you configured parameter "Receiver ACK Delay"?

Thank you,
--Bruno

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Tue, 3 Aug 2021 09:13:04 +0000

Some more questions on S13 (speeding UP, aka sensing the receiver performance)

Can you clarifying the definition of the three measurements reported (LSPTxMax, Tx, RxAv)?

So far, it seems that LSPTxMax is always higher than RxAv, i.e. the sender's estimation seems higher than the receiver capability.
Could you elaborate why there is no loss of LSP?
Trying to guess on my side (since the algorithm is not published in the draft):
a) LSPTxMax seems in advance of phase (compare to the real sending rate)
b) the receiver seems buffering the LSP in excess rate. i.e. the algorithm seems to take benefit of a buffer that he knows nothing about (and may be specific to your implementation). Do you know the size of this buffer (either from implementation knowledge or from measurements)? If not, you could please send the rate data so that I can compute the one used. (looking at the second figure, the buffer seems to be at least 400LSP (220*(15-13) which a conservative measurement on the graph)

The second figure is showing two bursts.
Why/how has the sender paused?

Thank you,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, August 3, 2021 10:41 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: [Lsr] IS-IS flooding

Les,

S6:

S9:

Thank you,
--Bruno

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 3 Aug 2021 21:13:28 +0000

Bruno -

Inline.

From: [email-masked] <[email-masked]>
Sent: Tuesday, August 3, 2021 1:41 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: IS-IS flooding

Les,

S6:
What burst size did you use? And distributions of reals values if possible, if not (min, max, average, median) would be useful.
What scheduling frequency/period did you use on the sender?
[LES:] I did speak to this point during the presentation.
At faster flooding speeds (let's use 1000 LSPs/second as an example), it is unrealistic to expect that the IS-IS TX thread can expect to be scheduled 1000 times/sec - so a model of sending 1 LSP each interval is unlikely to achieve the desired rate.
(Something that is far more likely to work at 33 LSPs/second.)
So we try to compensate for irregular scheduling to achieve the target Tx rate/second. There is no fixed burst - what we do is adaptive so that in the course of a second we can achieve the current target rate.

S9:

[LES:] We have tried a variety of PSNP delay intervals because we expect that in the real world different implementations are currently using different values and while we agree with you that we want to advocate using shorter PSNP delay timers - we do not want to require it in order to have the faster flooding work. All of the test results presented used 0 PSNP delay plus a fixed propagation delay of 500 ms.

   Les

Thank you,
--Bruno

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 3 Aug 2021 22:10:16 +0000

Bruno -

From: [email-masked] <[email-masked]>
Sent: Tuesday, August 3, 2021 2:13 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: RE: IS-IS flooding

Can you clarifying the definition of the three measurements reported (LSPTxMax, Tx, RxAv)?
[LES:] LSPTxMax on the slides really should be LSPTxRate i.e., the current target rate for sending LSPs.
Tx is the actual number of LSPs sent in the most recent 1 second interval. This lags LSPTxRate, especially when slowing down (easier to see on Slide 9).
Rx is the actual number of ACKs received in the most recent 1 second interval.
On Slide 13, since we are speeding up, Tx == Rx and the Tx colour has been overwritten by the Rx colour.

So far, it seems that LSPTxMax is always higher than RxAv, i.e. the sender's estimation seems higher than the receiver capability.
Could you elaborate why there is no loss of LSP?
[LES:] Slide 13 is a case where the receiver has recovered from some earlier transient load and is now capable of sustaining a higher receive rate. As we increase LSPTxRate, the Rx line follows - but lags in time because of propagation/ack delays. But since the Receiver is able to process more LSPs/second than we are sending there is no loss.

[LES:] In the tests we ran there were no actual drops due to buffer exhaustion.  We did however artificially create drops at the receiver to test at the lower rates.
This is one area we are going to do more testing as we realize that we also need to test lower rates where the receiver does not drop, just lags in processing the received LSPs because of load.

[LES:] We have an LSPDB size of 2K in our simulated network. In the case of LSPTxRate of 1000/sec, we did not ramp up from 100 to 1000 LSPs/sec in the time it takes to flood 2000 LSPs. We needed to trigger another "event". The quiet period in between is simply the delay before we triggered another flood of 2000 LSPs.

   Les

Thank you,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, August 3, 2021 10:41 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] IS-IS flooding

Les,

S6:

S9:

Thank you,
--Bruno

Thank you.

Thank you.