IS-IS Fast Flooding
draft-ietf-lsr-isis-fast-flooding-09
Discuss
Yes
Jim Guichard
John Scudder
No Objection
Recuse
No Record
Deb Cooley
Francesca Palombini
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Warren Kumari
Éric Vyncke
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Zaheduzzaman Sarker
Discuss
Discuss
(2024-04-04 for -08)
Sent
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
(2024-04-04 for -08)
Sent
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?
Jim Guichard
Yes
John Scudder
Yes
Erik Kline
No Objection
Comment
(2024-03-30 for -08)
Sent
# Internet AD comments for draft-ietf-lsr-isis-fast-flooding-08 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments * I like that it's Experimental, but it might be good to have text around what a "successful experiment" would like for when/if this comes back around to be elevated to Standards Track. I'm assuming a successful experiment includes plenty of "plugfest" interoperability testing. But of more interest would be having some report about congestion control lessons learned (vis S6 proposals).
Roman Danyliw
No Objection
Comment
(2024-04-03 for -08)
Not sent
Thank you to Ines Robles for the GENART review.
Gunter Van de Velde
Recuse
Comment
(2024-04-02 for -08)
Not sent
I am an author of this one.
Deb Cooley
No Record
Francesca Palombini
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Warren Kumari
No Record
Éric Vyncke
No Record