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

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/



----------------------------------------------------------------------
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?