Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

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 <[e-mail]> 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) <[e-mail]> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Friday, April 5, 2024 9:37 AM
To: Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>
Cc: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi Les,


On Apr 5, 2024, at 12:17 AM, Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>> 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
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HTCx0P9N7YA4OQn8WEvMhmr2_VzAQHNQcZID1KxgWWfo5GBd9msku8oTGLhQFMzBAcuk2mpjNIyvUicgYfWemQU8BXu1$