Bruno - From: bruno.decra...@orange.com <bruno.decra...@orange.com> Sent: Tuesday, August 3, 2021 2:13 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: lsr@ietf.org Subject: RE: IS-IS flooding
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)? [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. 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) [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. The second figure is showing two bursts. Why/how has the sender paused? [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:lsr-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Sent: Tuesday, August 3, 2021 10:41 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Cc: lsr@ietf.org<mailto:lsr@ietf.org> Subject: [Lsr] IS-IS flooding 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. _________________________________________________________________________________________________________________________ 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.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
