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

[[e-mail]]

Zahed,

Thank you for your review and comments.
Sorry for my delayed response.

Les has already commented on the algo 2 section.

Please see inline for other points [Bruno]

>
> -----Original Message-----
> From: Zaheduzzaman Sarker via Datatracker <[e-mail]>
> Sent: Thursday, April 4, 2024 12:17 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)
>
> --------------------------------------------------------------------------------------------------------------
> CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender.
>
> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur.
> --------------------------------------------------------------------------------------------------------------
>
> 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?

[Bruno]
Sorry it's not clear to me if by "multiple input queues" you mean in parallel (e.g. for different IS-IS neighbors or different incoming traffic) or serial (consecutive congestion points).
Also by " the flow and congestion control algorithm 1" is this specific to flow or congestion control?
Regardless, I'll try an answer and please refocus me as needed.

Flow control assume the existence of a control plane buffer e.g. in the socket. In the general case, there may be one per IS-IS neighbor or one shared by multiple neighbors. In the first case, the size of this buffer is advertised as the rwin. In the latter case, the size needs to be split across those neighbors. (In more details, some room need to be kept to handle some IS-IS traffic which is not flow controlled such as Hello and PSNP).

Congestion control does not make much assumptions because it seems like router architectures may be quite different and for the complex cases (chassis with multiple line cards) the internal are a secret sauce. However during out test we only introduced a single and simple congestion point.
On a side note, we have presented some tests results at IETF 111. If you want to have a look at them, please find below the slides. If you have some comments on the tests results, I would be obviously interested in your comments. Either on the list or of the list.
https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00.pdf

As far as I understood it, the motivation for congestion control algorithm 2 is that:
- determining rwin may be difficult when the same software runs on very different hardware and that no API exist to get that info;
- the congestion control algorithm may cover the functionality of the flow control in which case implementing only the congestion control is simpler than implementing both
- flow control requires both the sender and the receiver to be upgraded while congestion control algorithm 2 could cover existing implementation including in their various forms...

> Why is that easy for the case of algorithm 1?

[Bruno] In our implementation (Free Range Routing) determining rwin has not been found to be a problem.


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

[Bruno] My guess is that each implementation makes its choices based on its constrained.
Algo 2 is supposed to adapt to any receiver but as you stated the detailed are not specified.
Algo 1 flow control needs two things from the receiver:
-a- the advertisement of the received window.
-b- acknowledgements faster than the original ISO spec in order to get a feedback loop and to "release" the window.

In the absence of "a" the value could be locally configured on the sender. This is covered in the document.
In the absence of "b" the performance will be affected (but not worst than today)

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

[Bruno]
>From a protocol perspective, IS-IS does not even have a layer-3 (at least IP) so a layer-4 is not readily available.
The LSR WG considered using TCP/IP with draft-hsmit-lsr-isis-flooding-over-tcp. In short, the requirement to use IP (with same version on both side) was seen as a significant change.
Also, IS-IS only lacks flow and congestion control while layer-4 usually brings other functions. In particular, the "reliability delivery" is already covered by IS-IS and there would be duplication. Also we don't need/want ordered delivery.

Surely, the ISO, which originally specified IS-IS, was aware of network layers and the benefit of layers, including layer 4. I was not there at this time so I don't know why precisely they didn't use a layer 4. I guess that at the time it was felt that using static constant would be good enough. Scaling and routing convergence requirements were much different though. Also IS-IS flooding is the hard part and it (really) needs to work so there is probably also a desire for control. (Also I've been told that for BGP -which uses TCP- it's not as simple as "just using TCP")

Regards,
--Bruno

> - 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?
>
>
>
>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.