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

[Zaheduzzaman Sarker <[e-mail]>]

Hi Les,

Thanks for taking the stab, it is a good start but no quite there yet.

- Now 6.3 and 6.3.2 has the same section title. I would rename section 6.3
to "Transmitter side congestion control considerations" and 6.3.2 to
"Guidelines for transmitter side congestion controls". Note that here
"transmitter side" congestion control would particularly mean that the
transmitter is in sole change of doing congestion congestion control based
on say - performance measurements of any sort.
- Rest of changes looks good to me, however, I am not sure we should use
normative text to describe guidelines, unless we say those are requirements
and then perhaps also describe how one should fulfill those requirements.
My understanding is we don't want that sort of details here. I would
recommend to remove all the normative SHOULD and relay on implementer doing
the right thing. We are anyway not doing standard algorithm (s) and
accepting implementation details would vary.
- I am expecting this document to call out the algorithm 1 as the only one
it is defining/describing and 6.3.2 are guidelines for other approaches
when Algorithm 1 is not feasible. This should be reflected in the document.

//Zahed

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