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

[Zaheduzzaman Sarker <[e-mail]>]

Hi,

What you have in 6.1 paragraphs is great, those are nice way to put apart
flow control and congestion control.
However, what you have in section 6.3.2 is not complete description of the
congestion control and it provides some guidelines to design a congestion
controller. That is the issue I have. I think it would be just fine to say
one can design a congestion controller based on on the rate of
acknowledgements received and here is some guidelines one might consider.
Rather calling the whole thing a separate congestion control.

In my view, you have three congestion signals to take into account - 1)
loss, 2) delay and 3) rate of acknowledgement received. You can put
together all those signals to device congestion control algorithm. Now,
rather describing the congestion control algorithm we make sure that the
IS-IS control plane have all the ways to provide those signals to the
transmitter to react. And we left the choice of congestion control
algorithm to the implementers and define a circuit breaker which will MUST
to implement as last resort. If we want to define the congestion control
algorithm then do it properly with all the details required to implement
such standard congestion control for IS-iS and CCWG is the right place to
do it.

Here we are neither stopping by describing the signals only nor defining
the congestion controller with required details.

//Zahed

On Fri, Apr 5, 2024 at 6:18 AM Les Ginsberg (ginsberg) <ginsberg=
[e-mail]> wrote:

> John/Zahed –
>
>
>
> In regards to Algorithm 2, note that older versions used the term “Flow
> Control”, but based on the discussion with Mirja (not that I am blaming
> her…) we changed that section to use the term “Congestion Control”.
>
>
>
> This seems proper to me. If one looks at Section 6.1 – and in particular
> paragraphs 2 and 3 – congestion control seems like the correct choice.
>
>
>
>
>
> Zahed – I would appreciate your updated response after rereading those
> paragraphs.
>
>
>
> John – I am not entirely clear on what would address your comment. Would
> replacing “algorithm” with “approach” in Section 6.3.2 be satisfactory?
>
>
>
>   Les
>
>
>
>
>
> *From:* John Scudder <[e-mail]>
> *Sent:* Thursday, April 4, 2024 6:59 AM
> *To:* Zaheduzzaman Sarker <[e-mail]>
> *Cc:* 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)
>
>
>
> Hi Zahed,
>
>
>
> I guess the authors should respond comprehensively. I do have one response
> to your comments on algorithm 2, though. They seem to boil down to your
> first comment, "Can we really call congestion control algorithm 2 a
> congestion control algorithm?” It seems to me, on looking at the document
> again, that the answer is probably “no”. From §6.3.2, with emphasis added:
>
>
>
> "When congestion control is necessary, it can be implemented based on
> knowledge of the current flooding rate and the current acknowledgement
> rate. **Such an algorithm is a local matter and there is no requirement or
> intent to standardize an algorithm.** There are a number of aspects which
> serve as guidelines which can be described."
>
>
>
> I wonder if it’s both necessary and sufficient to reword “algorithm” 2 to
> be called something else, and to remove the RFC 2119 keywords from 6.3.x.
> As I read the quoted text, it’s not an algorithm, it’s hints towards an
> algorithm.
>
>
>
> Looking forward to your comments and those of the authors.
>
>
>
> —John
>
>
>
> On Apr 4, 2024, at 6:16 AM, Zaheduzzaman Sarker via Datatracker <
> [e-mail]> wrote:
>
>
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-lsr-isis-fast-flooding-08: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!C4IK0qxrHCShIaZBQk48oNHSXQ7rb3GAhaymBNFbvj-okuR1iO8UDVkcxrsY1Kxfqj_vVLgd108E$
> <https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!C4IK0qxrHCShIaZBQk48oNHSXQ7rb3GAhaymBNFbvj-okuR1iO8UDVkcxrsY1Kxfqj_vVLgd108E$>
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!C4IK0qxrHCShIaZBQk48oNHSXQ7rb3GAhaymBNFbvj-okuR1iO8UDVkcxrsY1Kxfqj_vVG87RLDF$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!C4IK0qxrHCShIaZBQk48oNHSXQ7rb3GAhaymBNFbvj-okuR1iO8UDVkcxrsY1Kxfqj_vVG87RLDF$>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for working on this specification. Thanks for Mirja for the TSVART
> review.
>
> I would like to discuss the following points as I believe some
> clarifications
> would help -
>
> - Does the flow and congestion control algorithm 1 assume that there is
> only on
> (input)queue in a particular link? I understand that the motivation for
> congestion control algorithm 2 is that there are multiple input queues and
> defining rwin is difficult. Why is that easy for the case of algorithm 1?
>
> - Can we really call congestion control algorithm 2 a congestion control
> algorithm? We are are really solving the problem of flow control, it
> sounded
> more like a emergency break ( aka circuit breaker ) to me where you reduce
> or
> even stop sending LSPs. My point is I am not sure how to interpret the
> congestion control algorithm 2 with any sort of details. If I replace
> section
> 6.3.2 with - "if the routing architecture does not support deterministic
> rwin,
> the transmitter MUST adapts the transmission rate based on measurement of
> the
> actual rate of acknowledgments received." what harm would it cause?
>
> - For the congestion control algorithm 2, I am missing when the transmitter
> should reduce or when it should stop sending as I am not sure reducing the
> transmission rate would solve the problem of not. This comes from lack of
> details on the particular algorithm that will be implemented eventually.
>
> - Section 6.3.2. says -
>
>    The congestion control algorithm MUST NOT assume the receive
> performance of
>    a neighbor is static, i.e., it MUST handle transient conditions which
>    result in a slower or faster receive rate on the part of a neighbor.
>
>  How to separate the persistent congestion from transient slower receive
> rate?
>  I am not sure how to fulfill the "MUST".
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I have some further questions or comments -
>
> - How does the implementers select between congestion control (CC)
> algorithm 1
> and 2? or is the intention that both gets implemented and after
> experiments we
> pick one? As in my discuss point I am not sure about the CC algorithm 2 on
> how
> to conclude on the experiments.
>
> - It already says flow control and congestion control is a Layer-4
> responsibility, it would be great if we can say why that is not the
> preferred
> layer for fast flooding even if it may be obvious for some of us.
>
> - Section 6.3.2 says -
>
>    When congestion control is necessary, it can be implemented based on
>    knowledge of the current flooding rate and the current acknowledgement
> rate.
>
>  So, how do we know when the congestion control is necessary?
>
>
>
>