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

[Zaheduzzaman Sarker <[e-mail]>]

Hi Bruno,

My apologies too :-) , I was on PTO

My responses inline below.

//Zahed

On Tue, Apr 9, 2024 at 5:13 PM <[e-mail]> wrote:

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

I was considering 6.3.1 kind of setup.


> Also by " the flow and congestion control algorithm 1" is this specific to
> flow or congestion control?
>

The fact is it was not clear to me if flow control in section 6.2.1 is an
independent solution to the problem or is part of the Algorithm 1. Over all
it is now not clear to me what should I implement from 6.2...Is
implementing the flow control described in 6.2.1 is good enough? or do we
need flow control and congestion control both to be implemented?



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

Right and I am under the understanding that the first case is where the
6.2.1 is only valid, am I wrong?

On the shared queues what happens if Algorithm 1 is implemented by some and
Algorithm 2 implemented by others? on a shared queue to get the goodput we
need fairness among the competing algorithms.


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

Have you run any test with two different algorithms sharing same 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
>

This should be in the document and very important one.

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

This is also information to share.


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

Again. does Algo 1 include both flow and congestion control?


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

is b discussed in the document?


>
> >
> > - 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")
>

I think a summery of what you wrote would be very useful to describe when
we are doing congestion and flow control in this document. Currently it
just says it is L4 job and we are defining flow control and congestion
control, without answering why.

//Zahed


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