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 protected]] On Behalf Of [email protected] Sent: Tuesday, August 3, 2021 10:41 AM To: Les Ginsberg (ginsberg) <[email protected]> Cc: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
