Top posting one comment. Regarding
<snip> [Bruno2] Well, I have large freedom to express myself in an email. Writing a summary of WG history in an RFC is a little bit more engaging... Also, although the perspective may be of interest, it’s less likely of little interest to an IS-IS implementor. I would propose the below addition in §6.1 “overview” but I’d very much welcome the opinion of chairs and responsible AD on this text. (both added in destination of this email) OLD: Ensuring the goodput between two entities is a layer-4 responsibility as per the OSI model. A typical example is the TCP protocol defined in [RFC9293] that provides flow control, congestion control, and reliability. NEW: Ensuring the goodput between two entities is a layer-4 responsibility as per the OSI model. A typical example is the TCP protocol defined in [RFC9293] that provides flow control, congestion control, and reliability. In order to improve the IS-IS goodput an option would be to carry IS-IS in a layer-4 protocol. However this creates challenges as IS-IS does not use IP so existing layer-4 stacks using IP are not readily available. Also IS-IS already have reliability mechanisms which would create duplication and possibly interference. Finally, many layer-4 providing flow control also provides ordered delivery which is not required for IS-IS and even harmful. <end snip> IS-IS runs directly over Layer 2. The solutions proposed in this document are for IS-IS as it is currently defined. The question of whether to run IS-IS over Layer 3 and if so how to do it are not in scope for this document. If a definition of running Is-IS over Layer 3 ever becomes standardized, how that may impact fast-flooding is just one of many aspects which will need to be addressed. I feel very strongly that we should not conflate this document by discussing such issues. Les From: bruno.decra...@orange.com <bruno.decra...@orange.com> Sent: Thursday, April 11, 2024 11:53 AM To: Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com>; lsr-cha...@ietf.org; John Scudder - Juniper (j...@juniper.net) <j...@juniper.net> Cc: Zaheduzzaman Sarker <zaheduzzaman.sar...@ericsson.com>; draft-ietf-lsr-isis-fast-flood...@ietf.org; lsr@ietf.org; acee.i...@gmail.com; acee-i...@gmail.com; The IESG <i...@ietf.org> Subject: RE: Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT) Hi Zahed, Please see inline [Bruno2] From: Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com<mailto:zahed.sarker.i...@gmail.com>> Sent: Thursday, April 11, 2024 11:33 AM Hi Bruno, My apologies too :-) , I was on PTO [Bruno2] No problem. I was also partly on PTO and I would also hope to be next week. My responses inline below. //Zahed On Tue, Apr 9, 2024 at 5:13 PM <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> 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 > <nore...@ietf.org<mailto:nore...@ietf.org>> > Sent: Thursday, April 4, 2024 12:17 PM > To: The IESG <i...@ietf.org<mailto:i...@ietf.org>> > Cc: > draft-ietf-lsr-isis-fast-flood...@ietf.org<mailto:draft-ietf-lsr-isis-fast-flood...@ietf.org>; > lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; > lsr@ietf.org<mailto:lsr@ietf.org>; > acee.i...@gmail.com<mailto:acee.i...@gmail.com>; > acee-i...@gmail.com<mailto:acee-i...@gmail.com> > 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. [Bruno2] Thank you for the clarification. That’s good as this is something that I can understand 😉 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? [Bruno2] flow control in section 6.2.1 is part of Algorithm 1 which is section 6.2 Implementing flow control in 6.2.1 is good enough if your internal router implementation will not significantly drop IS-IS PDU (considering 6.3.1 setup). E.g., if you have congestion for IS-IS traffic, you are capable of buffering it. (IS-IS is typically treated as high priority). Otherwise, adding congestion control will help. (in our tests, we had a rather simplified router, more like pizza box than chassis, and flow control was enough. We had to deliberately create congestion with a deliberate small buffer to see benefit from 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). Right and I am under the understanding that the first case is where the 6.2.1 is only valid, am I wrong? [Bruno2] 6.2.1 is valid in both cases. If multiple neighbhors share the same socket buffer one need to advertise rwin as buffer/number of neighbors. 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. [Bruno2] Good question. To begin with, contrary to typical transport goal, I don’t think that we require fairness between IS-IS neighbors. For IS-IS, assuming a single IS-IS level/instance, all IS-IS neighbors will advertise me the same packets/LSP. It’s does not matter whether I receive all LSPs from neighbhor1 only while neighbhor2 has zero goodput. Then to answer your question, in your scenario, algorithm2 would typically be more aggressive and get all the bandwidth. (although we don’t have details about algo2). IMHO likely algo1 would be less aggressive as its flow control RWIN is aiming at proving control without loss while algo2 is reacting when it has exceeded the capability of the receiver. And for algo 1 LSP loss would temporarily reduce the usable RWIN and hence the throughput (if the throughput was limited by RTT and RWIN size). Finally, please consider that currently there is zero flow control or congestion control algorithm specified for IS-IS. It’s all proprietary and different. (Possibly with little consideration for interop from some implementation). So I believe this document is a step in the right direction. 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? [Bruno2] No in our lab. But as there is currently no specified algo, and different vendors have different behaviors, well I’d say that multiple vendors networks experience this in live networks for about 2 decade (and even for single vendor, some vendors have changed their algo over the time) 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. [Bruno2] The first point is an implementation specific point/issue. This may be completely irrelevant for another implementation. I’ll leave the second point to Les as this is my understanding but he may have a different opinion. - 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. [Bruno2] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-09#section-5 already states that performance improvement on the receiver is needed in order to have a faster feedback (and more rythme) from the sender. I tend to believe that this is useful for both algo (as this looks difficult for the sender to adapt in the absence of feedback from the receiver) but I’m ok adding specific text in the Algo 1 flow control section. I would propose to add the following text at the end of 6.2.1. Flow control (i.e., just after the discussion on the impact of RWIN value on the performance, which start with “The RWIN value is of importance when the RTT is the limiting factor for the throughput.”) “Equally RTT is of importance for the performance. That’s why the performance improvement on the receiver, described in section 5, are important to achieve good throughput. If the receiver does not support those performance improvement, in the worst case (small RWIN and high RTT) the throughput will be limited by the LSP Transmission Interval as defined in section 4.2.“ (text subject to review from my co-authors) > 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? [Bruno2] already replied above (I believe) -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? [Bruno2] indirectly in 6.2.1 but the above proposed addition would make it more explicit. > > - 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. [Bruno2] Well, I have large freedom to express myself in an email. Writing a summary of WG history in an RFC is a little bit more engaging... Also, although the perspective may be of interest, it’s less likely of little interest to an IS-IS implementor. I would propose the below addition in §6.1 “overview” but I’d very much welcome the opinion of chairs and responsible AD on this text. (both added in destination of this email) OLD: Ensuring the goodput between two entities is a layer-4 responsibility as per the OSI model. A typical example is the TCP protocol defined in [RFC9293] that provides flow control, congestion control, and reliability. NEW: Ensuring the goodput between two entities is a layer-4 responsibility as per the OSI model. A typical example is the TCP protocol defined in [RFC9293] that provides flow control, congestion control, and reliability. In order to improve the IS-IS goodput an option would be to carry IS-IS in a layer-4 protocol. However this creates challenges as IS-IS does not use IP so existing layer-4 stacks using IP are not readily available. Also IS-IS already have reliability mechanisms which would create duplication and possibly interference. Finally, many layer-4 providing flow control also provides ordered delivery which is not required for IS-IS and even harmful. Thanks, Regards, --Bruno //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. ____________________________________________________________________________________________________________ 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.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
