P. S. With this change I guess you’d also want to change “algorithm 1” to just “algorithm.”
—John On Apr 5, 2024, at 4:33 PM, John Scudder <j...@juniper.net> wrote: [External Email. Be cautious of content] Thanks, Les. LGTM. It’s late in Zahed’s TZ so I’m guessing he might not get back to us until Monday. —John On Apr 5, 2024, at 3:07 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: Zahed/John – Here is a proposed revision of the section in question (not yet vetted with any of my co-authors). Have a read and let me know what you think. For your convenience, I have attached a diff file. Les 6.3.2. Transmitter Based Congestion Control The approach to congestion control described in this section does not depend upon direct signaling from the receiver. Instead it adapts the transmission rate based on measurement of the actual rate of acknowledgments received. When congestion control is necessary, it can be implemented based on knowledge of the current flooding rate and the current acknowledgement rate. The algorithm used is a local matter and there is no requirement or intent to standardize an algorithm. But there are a number of aspects which serve as guidelines which can be described. Algorithms based on this approach SHOULD follow the recommendations described below. A maximum LSP transmission rate (LSPTxMax) SHOULD be configurable. This represents the fastest LSP transmission rate which will be attempted. This value SHOULD be applicable to all interfaces and SHOULD be consistent network wide. When the current rate of LSP transmission (LSPTxRate) exceeds the capabilities of the receiver, the congestion control algorithm needs to quickly and aggressively reduce the LSPTxRate. Slower responsiveness is likely to result in a larger number of retransmissions which can introduce much longer delays in convergence. Dynamic increase of the rate of LSP transmission (LSPTxRate) (i.e., faster) SHOULD be done less aggressively and only be done when the neighbor has demonstrated its ability to sustain the current LSPTxRate. The congestion control algorithm SHOULD NOT assume the receive performance of a neighbor is static, i.e., it SHOULD handle transient conditions which result in a slower or faster receive rate on the part of a neighbor. The congestion control algorithm SHOULD consider the expected delay time in receiving an acknowledgment. It therefore incorporates the neighbor partialSNPInterval (Section 4.5) to help determine whether acknowlegments are keeping pace with the rate of LSPs transmitted. In the absence of an advertisement of partialSNPInterval, a locally configured value can be used. From: John Scudder <j...@juniper.net<mailto:j...@juniper.net>> Sent: Friday, April 5, 2024 9:37 AM To: Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com<mailto:zahed.sarker.i...@gmail.com>> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-lsr-isis-fast-flood...@ietf.org<mailto:draft-ietf-lsr-isis-fast-flood...@ietf.org>; lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org>; acee.i...@gmail.com<mailto:acee.i...@gmail.com>; acee-i...@gmail.com<mailto:acee-i...@gmail.com> Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT) Thanks, Zahed. Les and all, for clarity: please propose a revision, and then Zahed will take a look at it and sign off or raise any remaining concerns. —John On Apr 5, 2024, at 9:15 AM, Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com<mailto:zahed.sarker.i...@gmail.com>> wrote: Hi John, That might work, given that the content of the section also reflects the intention clearly and matches with the section title change. I can have a look if there is any proposed changes. //Zahed On Fri, Apr 5, 2024 at 3:00 PM John Scudder <j...@juniper.net<mailto:j...@juniper.net>> wrote: Hi Les, On Apr 5, 2024, at 12:17 AM, Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: John – I am not entirely clear on what would address your comment. Would replacing “algorithm” with “approach” in Section 6.3.2 be satisfactory? I think so, with the exception of “there is no requirement or intent to standardize an algorithm” which would remain as written. But this is really Zahed’s question to answer. Zahed?, does s/algorithm/approach/g in Section 6.3.2 (including section title) work for you, or do you have another suggestion? Thanks, —John <fast-flooding_approach.diff.html> _______________________________________________ Lsr mailing list Lsr@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HTCx0P9N7YA4OQn8WEvMhmr2_VzAQHNQcZID1KxgWWfo5GBd9msku8oTGLhQFMzBAcuk2mpjNIyvUicgYfWemQU8BXu1$
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
